Storing it locally works as long as you don't get robbed...
and your house don't burn down...
and you don't get hit by major disaster (i.e. flood)...
and your storage medium doesn't fail...

I keep mine locally (2 redundant systems) and in cloud

The point of the article wasn't to crack it, it was to show that if something sounds insecure by design, it is insecure...

DropBox allows you to "log in" to it's website via click in the application -> no credentials required. Therefore it must either store user credentials or some other secret(s) on client side (host_id and host_int in this case).

Any process running under privileges accessible to you can be cracked (albeit sand-boxing, in which case you need system privileges) and it can't hide data from end-user / other processes in same privilege space (albeit sand-boxing....).
They can make it more difficult though (extracting Bluray key from windows media player will take anyone at least a few days)

More and more big companies think they can hide data on client side and be secure. Dropbox, Windows Live (LiveConnect) and numerous others are now relying on fast exchange of nonces in addition to client-side secret storing to make it secure "enough".. But breaking the nonce handshake and authenticating in programmatic fashion will add maybe 10% more cracking/programming effort on top of the regular cracking effort.

TLDR: If it is insecure by design, it is insecure and no amount of obfuscation will help you....

You run the executable...
You ask kernel to stop executing it...
You dump the memory...
Voila - you have the unencrypted executable...
This process, including writing the tools for it, will take a person who knows what hes doing around 5 minutes... (if the program is large, it might take longer due to disk write speeds)...

Yes, they can obfuscate the assembly, but it still will be the assembly - perfectly human readable.
It might be pain to reverse engineer the whole program, but it can be done. But in most cases I've seen the hacker doesn't want to reverse engineer the whole program, he just wants to alter it a little / extract some crucial information from it (i.e. private keys). Obfuscation doesn't make this harder at all - You find some interesting OS level calls (i.e. socket creation - you cant obfuscate that...) and using debugger/stack traces/assembly/hooks you poke around a bit to find the part that is interesting to you...

From security point of view, assembly encryption (no matter how good it is) is comparable to covering your house with packing paper to prevent thieves from entering...

Estonia here

35 euro for 150/10 (146/10 on speedtest.net) uncapped, including cable (basic, 70 channels) and landline

40 euro for 100/50 4G LTE (91/44 on speedtest.net) uncapped, including unlimited calls and texts

3 euro for 5/1 3G (5/1 on speedtest.net), uncapped, no calls/texts included

Not installed at work (on 20 pc's in my department)
Not installed at home on 3 pc's and 2 macs
Installed on my old Droid and s60 phones, but not installed on any phones my family is using at the moment (2xW8, 1xIOS)

Can't find any "killer apps" that would compel me to install Java and *try* to keep it up-to-date/secure

We have few hundred employees and 2 actual physical fixed-line phones (at reception)
But we do have "fixed line numbers" for pretty much everyone

All is done over VOIP with intelligent back-end,
when someone calls me on my fixed number (or some call is redirected to me):
* If I'm behind my laptop, company IM rings in laptop with options to redirect/hold/answer via headset/answer via mobile/etc.
* If I'm away from my laptop (IM status auto changes after 5 min of inactivity), my phone and laptop ring at the same time (laptop silently), so i can answer it from my phone or do whatever from laptop
* If my Outlook/IM status is "DND" or my workday is over then i get a e-mail notification and the call is redirected to reception / help-desk (depending on caller)

Having and actual physical phone on my desk would mean that i miss 70% of calls (i have to move around the office quite a lot) and it would take up valuable desk space (where would i put my Chuck Norris motivational picture then :))

Had it for a bit under a week, so far no glitches and I'm really loving it!

ATM cells in your DSL line have ~10% overhead
each TCP/IP packet has ~2.5% overhead in best case
TCP/IP handhakes(and resets) might add another 2-3%

So 20% overhead in data transfered vs useful data is actually realistic over DSL line

This makes sense.. really...
If I'm a true fan, I have liked the page and am liking a lot of updates from the page... therefore FB sees that I am interested in the content provided by the page and i get 100% of hes updates
If i have liked the page by accident (or just don't really care about what it has to say), then i don't "like" the updates of the page and soon enough i will stop getting them... (except for really popular ones)
So if I'm not getting the updates, i DON'T CARE about them and its perfectly fair for FB to charge him for spamming my news-feed.
I understand that he has invested in advertising but hes got the return from that... a lot of users who liked the page and got temporary exposure to he brand.. expecting this to go on forever is like expecting that if you publish a TV ad, then every person who has seen one of your ad's is committed to see all your other adds (multiple a day) for the rest of eternity....
Also he forgets to mention that by doing a sponsored post, he will get exposure to users who have not yet liked hes page...

This actually is due to regulators, classifying the 13th work hour as overtime would entitle the employee to certain benefits and might be even illegal (i.e. emergency workers are allowed overtime only in case of large scale emergency in order to avoid mistakes from fatigue)

In some cases schedules of many organizations have to be coordinated (i.e. all ER crews/fire crews/etc. in a city cant have a shift change at the same time) so changing them is complicated and since in most cases people have worked out their schedule based on personal preferences, a lot would oppose the standard time based schedule (i.e. "sorry you cant pick up your kid from school in winter since you will be finishing at 4PM instead of 3PM").

What fun would be programming schedules / calendars / payrolls if we didn't have one 25h and one 23h day in a year.

On one specific day, we have to pay a worker for 13 hours while hes on a 12 hour shift and not count the extra hour as overtime
and on another specific day, we need to pay for 11 hours and still count the 12 hour shift fully filled.
If there were no DST then we could replace huge modules of business logic with just one or two lines of code... and thats bad for (our) business

Lets build a petrol power plant, direct its exhausts to this new CO2 -> petrol power plant and feed the created petrol back in the petrol power plant...
If we are efficient enough, we might have discovered a way to burn petrol without any pollution or energy created

In some cases, data-URI might be still faster (though less bw-effective), i.e if you take the original example and account for 54ms latency (3way handshake+initial response packet) then reloading the page (with all images cached) would take 0,054*20=1,08s since a query to the server for each image is still required

When using high-latency - high-throughput connection (i.e. mobile, satellite) then data-URI will be a lot faster than caching.

Take a website with 100 small images, with average image size 10kb, latency (3-way handshake+data) = 25ms, and your bandwidth = 10Mbit/s

Using 5 paralel connections (max allowed by http) the site will download in 10/1280*100 + 0,025*20 = 1,28 seconds

Embeding all images in original document using data URI's (~1.37x overhead to data size but no latency impact), the site will download in 10*100*1,37/1280 = 1,07 seconds

HTTP2.0 / SPDY will solve this, but it will take many years till they are widely adopted.

http://xkcd.com/1085//

Most of time noone cares what you have to say

When someone cares they will have the means to listen in

http://xkcd.com/538//