Every time this come up, its RFID ePassport this and RFID credit card that. None of these use RFID at all, the technology used is NFC. As for the RFID blocking jacked, pants, wallet etc. I have tried a number of these and yes they are good at blocking RFID access tags, but do only a little to reduce the range of NFC.

My thought here is, if anyone is performing an act in public that is perceived as illegal they should be expect to be recorded or even obstructed by a well meaning member of the public if not a police officer. Also, recording anything in a public place (excluding where that contravenes wiretap laws) is not in itself illegal, being a good citizen though means that if asked kindly to stop by anyone you need to stop unless you have a social imperative that impels you to continue.

But, it is all about perception, what you see as illegal might well not be. But the act of recording, if that is perceived to obstruct justice will open you up to legal proceedings.

Not sure in this case but openly and belligerently recording an officer will get you noticed and annoy them, which interferes with their duties and will open you up to closer scrutiny.

That said, and repeating myself, If ANYONE is committing an illegal act in public they should be expected to be recorded for evidence. But if you feel impelled to record anyone in such a situation make sure you do not also endanger your own safety by making it clear to the perp that you are collecting evidence against them.

This is a tricky one.

The old adage is that you have free speech only in so far as that is not used intentionally to cause harm i.e. Willfully shouting FIRE in a crowded theatre is well known. The key aspect here is willful speech, just shouting something like FIRE without willful intent is not enough and has occurred in differing circumstances because of illness or being miss-heard.

In this case the perpetrator has posted in a semi-public forum speech that could be construed as a manifesto of illegal action. If there were evidence that the actions were being planned or that there were a conspiracy in progress then that would be a convictable charge. But, the act of speaking of an illegal action you wish to do (especially in public) even if there is intention is still protected, but only in so far as that society may take that intention into account in restricting your movements by legal torte.

In Summary, you can declare you full and willful intention to 'Kill' your enemy. But if you do, don't be surprised if they are forewarned and take restrictive legal action against you. Conversely, any reasonable person would not do such if they did intend to perform the act as speaking out would mark them clearly as the perpetrator. Unless they feared no prosecution.

One question I always ask myself when I read of the publication of any private matter from a public person. What if that happened to me or any other private person I know? What would I want others to do?

Clearly I would want responsibility and respectfulness, perhaps a kind admonishment for not taking enough care (if that is due) with a note that they also have done dumb things in their life. I would also expect recognition that the perpetrator could have struck them and support in making sure this does not happen again.

In this case though that is rarely what happened, everyone seemed to become polarized either in support of these public people against the haters or were themselves haters. What seems never to be mentioned is that the hack involved was probably not a targeted one and that the perpetrator is probably sitting on Giga Bytes of private data from a wide swath of individuals, both public and private. If it were not though for their ego in publishing the salacious images of those people already in the public eye we would never have known and would have gone on blindly with our weekass passwords.

So think on this, next time to upload anything potentially useful to an adversary. Next time it could be YOU!

So pick your passwords with care, employ strong second factor authentication and if you just have to send a naked selfy to your significant other learn how to use end-to-end encryption. Because believe me, we really don't what to have to look at your naked self above the fold over breakfast tomorrow.

This sort of idea can make you more valuable dead to those who want the information leaked in one massive hit, so it can be run through the 24 hour news wash and then forgotten.

If Apple proceeds with locking away the NFC API from developers they will be making a Huge mistake. NFC is not just for payments, it is a use agnostic technology, and as such can be used anywhere you need short (1-2") data communications i.e.
# Door locks / home security
# Wifi tap to secure.
# Bluetooth Pairing
# End to end encrypted messaging tap to exchange / sign public keys
# Second factor online authentication
etc etc.
On Android all these uses are available because the API is open.

You imply a backup but your current setup does not provide it, Peter Krogh had is succinctly in his 3-2-1 rule see: http://dpbestflow.org/node/262... at bottom

In summary, as well as your two local copies you need an offsite backup, possibly from a trustworthy cloud vendor.
  This all depends though on if the vital media is really worth preserving. If they really are, historic documents that should be preserved for all time you should think about investing in some analog archive storage, as well as the digital to forgo the risks of technology drift overcoming your ability to update the format as new systems replace old formats i,e. Some archive quality 35mm B&W colour separation movie film with integral optical sound recording. Thus can be expensive though for your average family movie, but just think what it will be like in a millenium when yours is the only home movie left in existence ;-)

The 3-2-1 Rule
The simplest way to remember how to back up your images (ed: or any media) safely is to use the 3-2-1 rule.

We recommend keeping 3 copies of any important file (a primary and two backups)
We recommend having the files on 2 different media types (such as hard drive and optical media), to protect against different types of hazards.*
1 copy should be stored offsite (or at least offline).
*While 3-2-1 storage is the ideal arrangement, it's not always possible. A second media type, for instance, is impractical for many people in the ingestion or working file stage. In these cases, many people make do with hard-drive-only copies of their data. Best practices, however, still require 3 copies and some physical separation between the copies.

Ok, so an EU library can scan works for access on their own 'terminals' for research. Can they also make those works searchable in a similar way to that which Google does? And if so can they allow access to that index (like their book index) over the internet?

If they can then at least in the EU Google has a copyright exception if it partners with at least one EU library organisation, to their Google Books project.

http://www.seatguru.com/

I would love to see the financial analysis of this i.e.

Remove 1" of leg room to get in x extra seats and make n dollars per extra customer
  VS
Cost of an interrupted flight due to personal space induced aggression.

I have a feeling that with margins being squeezed and the high cost of missing your allocated airport departure / arrival slot, it may well work out that keeping customers happy is actually more profitable than skimming them for every inch and dollar.

See:- https://www.grc.com/sqrl/sqrl....

Using a smartphone as your token, and if that is not secure enough for you, I am for my sins presently building an HSM that will interface over NFC with the smartphone to keep all the cryptography parts and master key outside of the potentially vulnerable computing platform. Further I promise as do many of us working on this project to make everything we can public domain or at the least open licensed.

Before making comment on this please do read and digest all the reference material, TL;DR; does not cut it in crypto.

Do they mean http://www.projectsunblock.com... ?

Seems likely, and if so the ad serving network would have to cooperate in allowing sunblocks JS to be served to client browsers. I can only home the Met's and Cities finest have a 100% accurate blocklist, because it only takes one high profile false-positive and a suit for loss of earnings due to illegal seizure of assets to drain sunblock dry.

Agreed what this paper says is a really bad idea, but the bigger question is why do you need to protect your low value digital assets with equivalent security to your high value ones with strong unique passwords.

The reason is, as is mentioned you will have many more low value assets with apparently insignificant information stores than the few that store critical information. So that if say you reuse a week password on all these low value sites a single break in any of them will potentially give an attacker access to all of the rest as it is known that once an attacker gets a username/email and a password (reversed from a week hash) say they will try that username/email and password everywhere they can. It thus will be not a single tiny piece of information you risk with this policy but every piece of information on all the sites you risk and that may well add up to something very saleable to an attacker.

So what do we do?

0/ We cannot go around with many unique strong passwords in our head for fear of leakage and loss of retention.
1/ We could use a password safe, provided we trust the vendors or our skill to write it and not later make what is now a strong keeper weak by software patch.
2/ We could use a high entropy deterministic password generator e.g: https://www.grc.com/offthegrid... if we have the time to work the manual algorithm each time we want a password.
3/ We could do away with almost all passwords by use of Oauth / SiteID etc. Provided we trust a third party in all logins to not track our use.
4/ We could do away with All but one single pass-phrase that would potentially allow us to pseudonymously identify everywhere like SQRL, but that is early days and will need time to be supported.

What I am saying is there is no single solution but many, but for certain the one suggested in the paper is not one of them...

I think I did!

Except the attack senario is an SQL injection. So how will you be exposing this in-memory data to the web app?
BTW: most database engines already put commonly used tables in RAM for efficiency, so its already done and does not help.