zorlem

I highly doubt that. The risk is too high.

In my country there was a big scandal a few years ago when a couple of radio stations started playing Billboard Hot 100 songs. I guess they couldn't source the new songs in time from reputable sources for some reason (licensing restrictions, logistical failure, no idea...).

So they simply downloaded them from local torrent trackers. The thing blew up, because a guy that was uploading and seeding the albums put his own catchy promotional jingle in the middle of most songs.

Use Shamir's Secret Sharing Scheme [0] to store your master password and distribute pieces of the key to several relatives and close friends.

[0] http://point-at-infinity.org/ssss/

Take a look at Keepass2Android, I like it a lot.

An "acceptable" alternative would be to implement an indirect clipboard in which a trusted keyboard application can replay the string for a short duration but that's not going to happen either.

Actually Keepass2Android does just that - it provides an (optional) dedicated keyboard layout that you can install and activate.

Whats worse is that probably most people who use a PWM on a mobile device choose to have a PIN lock on it after supplying the initial PW which reduces the PW complexity even further.

Some password managers have the option for using a part of your password after the database is unlocked - you get a limited number of tries (configurable) and the database locks if you don't guess the short code.

I, too, don't like the way MongoDB works and is marketed, but I would not bet too strongly on them failing. Only 10 years or so ago MySQL did pretty much the same, but they managed to succeed, despite there being better alternatives at the time.

Even today, after all the development effort put into MySQL and its derivatives, there are still better and more capable databases, but that doesn't prevent MySQL from being one of the top three RDBMS-es (and we can bet it is the most popular FOSS RDBMS).

Depending on your needs you might check git-annex, unison and others mentioned in other comments.

To answer that you will have to define "trustworthy". I'm personally leaning toward trusting the curves proposed by Dan Bernstein [1], since he clearly explains the reasons for choosing the specific parameters and they're demonstrably valid.

[1] http://cr.yp.to/ecdh.html

And what if it's not your PhD thesis in Libre Office but a busy database server which can easily get corrupted if you don't flush.

No properly configured and working ACID compliant RDBMS should lose any data when the server is reset or stopped. If it does, then it is either a problem with the hardware, OS, configuration or the RDBMS itself. The application must also be able to handle the DB disappearing, though. Sadly this is often not the case.

You do it by breaking up the potentially destructive changes so you could rollback your deployment to the previous working version. Typically all destructive modification of the schema is done in several passes: eg. in each release/deploy:

# copy the data in a new table and add code to place it in both tables

# change the code to reference only the new data but still store it in both tables

# rename the old table

# remove the old table

On top of that you have changes that are supposed to be applied before the new code is deployed (eg. creating a table, renaming a table) and after the code is deployed (eg. dropping unused columns).

As somebody else mentions in the comments this is more about Change Control than Versioning, but the two things go together to insure that you have as much idempotent and reversible changes as possible. Of course, if you have the resources you can always adopt a "never delete data" policy, so you're always copying instead of modifying the data, making sure you have a way to retract the changes. Clean-up can be done on regular, distant intervals.

Using ORM doesn't prevent you from doing a review on the changes that are about to be implemented. ActiveRecord for example, could provide you with a SQL file that will be representing your schema after the ORM is done. Usually the ORM schema changes are executed automatically by your CI upon deployment on Dev, QA and possibly Staging environments (you do have at least two of those, don't you? :) and need manual intervention (maybe to control performance degradation of your live env - locks, increased disk I/O, etc). This way you get plenty of testing of any DB changes and you should be able to spot any problems as early as possible.

Since 2011 McDonald's changed their process http://news.yahoo.com/blogs/sideshow/mcdonald-confirms-no-lo...

It would be nice if you quoted some reputable source or research when making such bold claims.

Who are the people that can recover more than 1 rewrite easily from a modern hard disk drive, do you have any URLs at hand?

You could check Peter Gutmann's research titled "Secure Deletion of Data from Magnetic and Solid-State Memory" [1] from 1996 which is one of the original sources for "35-cycle erase" [2]. In this paper he states that it is possible to recover the data using a specialized microscopy equipment (using Magnetic Force Microscopy or MF Scanning Tunneling Microscopy techniques). These techniques are only applicable for mediums with a much lower magnetic density and much simpler encoding than are used these days (eg. RLL encodings like MFM, PRML, etc.).

How did you arrive at the number 50? In the epilogue of his paper Gutmann states:

In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes.

tl;dr: overwriting 35 times is a pointless waste of time and is one of the popular myths that refuses to die. Using shred under GNU/Linux or DBAN to overwrite with some random data is more than sufficient for our purposes.

[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

[2] http://en.wikipedia.org/wiki/Gutmann_method

The only sensible long-term solution for Linux seems to be to adopt FreeBSD's way of /dev/random operation - block once until enough entropy is gathered and then never block.

This would make sure that distro vendors don't even get a chance to mess initial seeding at boot time. It will also force vendors of embedded or "cloud" distributions (eg. Ubuntu's AWS images) to find a way to pre-seed the images to reduce the initial boot times.

Unfortunately there is such a huge amount of software that depends on this particular difference between /dev/random and /dev/urandom that I don't see the change happening soon.

I wouldn't bet hard money that it doesn't exist, there is always Rule #34.

http://xkcd.com/305/

In addition (or even instead of) to htop I strongly recommend atop [0]. This tool has been of an invaluable help to me during a lot of diagnostic sessions.

It can collect detailed memory usage profile of processes and when combined with some smart scripting it has a nice leak detection functionality [1]. Very useful when you run out of memory and want to find which daemon has used all of it.

[0] http://www.atoptool.nl/

[1] http://www.atoptool.nl/download/case_leakage.pdf

edit: formatting

The poster says in the first sentence of his post that it is Stripe [0] (his payment processor), not him, that stores the CC info.

[0] https://stripe.com/

The way I can think of is using IAM credentials to allow modification of a Route53 record using the AWS CLI from the newly spun server. You will need to write a short script that you could push to the new instance either through EC2 MetaData or UserData fields.

If there is a demand I could try whipping up a CloudFormation template to do it.

This idea (a throwable ball with imaging and other sensors) and several prototypes have appeared on HN before, the first one around 2 years ago. This exact product has reached the HN front page in the beginning of 2013 [1].

I find it strange that none of the prototypes have actually managed to reach a production stage, given that the potential market - military, LE, emergency responders is (supposedly) there. Maybe the price point doesn't make much sense, given the usual (low) prices for fixed-focus camera modules - there is no need for very high resolution here, and the balls better be semi-disposable.

There are a few other designs (and patents associated with the concept) - [2], [3] and [4].

[1] https://news.ycombinator.com/item?id=4757971

[2] http://www.bostonglobe.com/business/2013/01/21/surveillance-...

[3] http://www.serveball.com/

[4] http://jonaspfeil.de/ballcamera (and HN discussion: https://news.ycombinator.com/item?id=3109899)

I wonder if the recently discovered problems with non-unique key parameters could be the result of the cooperation of particular network gear vendors with NSA.

https://factorable.net/weakkeys12.conference.pdf

https://www.usenix.org/system/files/conference/usenixsecurit...

This is one of the best (simple) explanations of Shamir's Secret Sharing Scheme [0] which has a solid working implementation [1]

[0] https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

[1] http://point-at-infinity.org/ssss/

You need a capable sysadmin anyways. It makes sense to pay her/him to design and scale your "platform" properly, especially if you're making any money from it.

That doesn't match what the article said. Also, if they already had his card then there would be no need to send a courier to his place and pick it up, that only increases their exposure and the risk of getting caught.

A clever scam with the land-line call.

I wonder where the fraudsters have got all his personal info (including his land-line phone number) from. Even if they got a hold of his receipt that shouldn't contain enough info to get all the other details.

The demo of the app looks really fascinating!

I tried installing colar app on an Android 2.3.6 (Samsung GT-S5300) phone, but it seems it's not compatible with that device. It's a low-end phone, so I guess I will need something more powerful.

Since Google Play doesn't display the device compatibility anywhere in the store (besides "This application is not compatible with your device") could you please state the application requirements somewhere on your pages?

Have you tried duplicity [0]? It encrypts the archives using GnuPG, uses two separate keys - one for encryption, the other for signing, and can store the backups using a multitude of protocols [1]: > Currently local file storage, scp/ssh, ftp, rsync, HSI, WebDAV, Tahoe-LAFS, and Amazon S3 are supported, and others shouldn't be difficult to add.

It is libre software and cross-platform. A number of front-ends address the issue of ease-of-use.

[0] http://duplicity.nongnu.org/ [1]: http://duplicity.nongnu.org/features.html

I have seen it in another Eastern European country - the sum of all mobile subscribers each operator claimed to have, exceeded the population by 50%. I attribute it mostly to marketing tricks like counting pre-paid cards that have not been explicitly canceled towards the general tally of active users. In general the operators try to appear to have more subscribers in order to entice more new subscribers to choose them.

I seriously doubt that the telecom regulatory bodies in these parts of Europe pay much attention to the coverage/subscription rates claimed by the mobile operators' marketing departments.

Of course some of the people have more than one SIM card, but with at least 3 major operators this simply doesn't add up.

EDIT: added the sentence about the lack of regulation

It strikes me that the organizations that can't update to the latest JRE are the really large enterprises still running IE6 and so on.

Not necessarily. I know quite a few companies that have stabilized their code against a particular version and lack the manpower and/or the money to constantly upgrade and deal with the newly introduced bugs in newer versions. They usually do the upgrades on a schedule (eg. once a year or every 18 months).

For most major deployments changing to a new version of the JVM is a non-trivial task.

edit: added a life-cycle

Oracle changed the distribution terms of TZUpdater from free (as in beer) to available only to paying customers at least half a year ago.

It should be noted, though, that this largely affects only users that for some reason can't update their JRE and are lagging behind the latest version. Oracle still provides up-to-date versions of the TZ data with the latest JRE.

It's not a big issue since one could use IBM's TZ updater tool or compile the TZ data from the raw Olson TZ database using javazic.jar available from OpenJDK.

The discussion and the original video from a few hours ago: https://news.ycombinator.com/item?id=5729703

Maybe this one: https://news.ycombinator.com/item?id=3723943 , but I'm still unclear if OP invention or break-through is for the same technology.

Not really. These things are hard to get right and stick to for prolonged periods of time. This requires practice and discipline.

Ordinary people (and even trained professionals [1]), get sloppy and make mistakes. Thus, this line from the presentation is golden:

"Amateurs practice until they get it right, professionals practice until they can't get it wrong.

[1]: Another excellent essay by the same person - grugq (of +HCU and Fravia+ fame) on the major OPSEC fuck-up by CIA in Lebanon and the factors that likely have lead to the full compromise of a big informant network, and possibly the deaths of a number of people [2]: http://grugq.github.io/blog/2013/03/12/anonymity-is-hard/

[2] http://www.wired.com/dangerroom/2011/11/pizza-cia/

added: even small things like complaining about freezing your ass off due to the cold weather, accidentally linking two nicknames, emerging at regular times (synced with a specific timezone) could be used to uncover your identitiy. As evidenced, slip-ups like could get you in jail. You can check the discussion from a few weeks back about the hassles of creating a truly anonymous page on Internet: https://news.ycombinator.com/item?id=5638988

A recent article about Mochizuki's proof https://news.ycombinator.com/item?id=5685166 that was a great read for the uninitiated like me.