There's actually a quite nifty principle that makes it relatively easy to build your own multitouch table: Frustrated total internal reflection.
The idea is based on internal reflection: Whenever lights hits the boundary between two materials with different density it gets refracted. If it goes from dense to less dense and the angle is flat enough it will reflect back. This is the principle behind fibre optics. It's also the reason why the water's surface looks "silvery" (like a mirror) when you're submerged and look up at an angle (i.e. not straight up).
Now imagine you have a plane of glass and you put LEDs around the edges that shine into it from the side. The light will zig-zag trough the glass and come out at the other edge. However, if you touch the glass you inhibit that total internal reflection because your finger is alot denser than the air and so the light will "leak" out the glass where you touch it, illuminating your finger. If you look at the glass from behind you'll see a bright spot.
Use a camera to detect that spot and you basically have a touchpad. To make it a screen you can put a translucent sheet behind the glass and project an image onto it (and use infrared LEDs).
See e.g. http://wiki.nuigroup.com/FTIR for some helpful images. Just google "FTIR touch screen" or similar for build instructions and blob-detection software.
What a fun question :) And there are some very cool answers!
A few things that come to mind from my life, from back when I was still a kid/teenager:
- Building a three-way marble-track switch. There are many marble tracks that have these two-way switches that alternate between two tracks, like this one here: https://theworkbenchutah.files.wordpress.com/2013/04/06-marb...
I wanted to build one that would evenly distribute marbles along three tracks. Took me quite a few prototypes until I finally had a working one. And all I had to work with was paper, tape, glue etc. No wood or metal, no bearings or precision mechanics, only a kid's craft stuff.
- A LEGO technics robot leg. This is a bit hard to explain without images. I wanted to build a legged robot (something spider-like) and needed legs that could move a foot both borward and back and also up and down. As the LEGO motors where quite big and heavy I didn't want to mount them on the leg itself (e.g. at the "knee") but have them all fixed inside the body and transmit their power via gears and shaft.
The problem here was, that the up-and-down-motion had to go trough the forward-and-back-joint which meant that whenever the leg moved forwards or backwards it would also move a bit up or down, even if the up-and-down-motor didn't move at all. So I wanted to decouple these two motions. This would be trivial to do in software but I was just a kid playing with LEGOs so I wanted a mechanical solution. I managed it by using a mechanical differential to actually subtract the one motion of the other.
Unfortunately, I then realised I didn't have enough motors for a full robot...
- Years later I was learning C++ and I wanted some kind of "linked variables" (I'm sure there's an official term for this): I.e. variables that would depend on others and would update whenever one of their dependencies changed. I though this would be a cool way of writing a GUI. With a lot of operator overloading and some abuse of the type system I could actually write things like
x = a + b * 2;
y = x / b;
And 'y' would update whenever a or b (or x) was changed.
I'm not sure if they really are the hardest problems I've ever solved, but it certainly felt so at the time ;)
Definitely HN is the latest in a long string of sites that were good until the general public discovered them, Reddit being the most recent example. You're right: love the suggestions here and I hope the signal : noise ratio remains favorable for a good long while.
That might very well be, but is it obviously so? What if there was a position that takes 19 moves to solve in the fastest way possible but the next-best solution takes 21 moves? Is there always a solution that takes an even number of steps?
Yes, there is. If the last turn is a quarter turn, replace it by a half turn and a quarter turn in the other direction. If it is a half turn, replace it by two quarter turns.
The set of possible configurations would split in an even and an odd set, so there would be configurations that can’t be solved in God’s number of moves.
(AFAIK, we don’t know God’s number if we count moves that way. I would guess it’s larger than 20)
You could, but it would be thermally quite bad: The only way for parts to cool would be through radiation, which is way less effective than convection (be it forced by fans or passive, as in OP's design.)
Password managers are best practice, but they are a reaction to the failures of passwords, rather than an attempt to replace passwords with a better proposal.
* Password Managers are good but inadequate as a solution because, at present, only a motivated set of any given number of users are likely to make use of them.
Do we want a solution that works well for all or nearly all users? Or will we simply settle for a solution that protects only ourselves?
At present, password managers are often third-party luxuries even though they are indispensable for basically every person. In truth, they are essential enough that standardized API hooks for password managers really ought to be baked into every consumer OS, and if we are serious about protecting users in a world where 86% of passwords are terrible, users should have to explicitly opt out of whether to use a password manager or not.
The only choices most users should be making are
* whether to use a default or nominated password manager,
* what physical tokens / 2FA approaches they want to use
* and whether they want their credentials to be stored in the cloud (convenient) or only ever stored locally (more secure, credential transfer fully under control of users).
Sites / Applications / etc requesting credentials should really provoke a standardized credential request UI on the OS, not have bespoke credential dialogues in a thousand different designs and approaches bleeding all over the internet.
The choice to have a distinct credential per site should not be a choice offered to most humans, because most humans will always make the wrong choice.
I do this but I'd love to have someone tell me why this is a terrible idea (apart from the obvious one of using a 3rd party sha256 calculator)
1. Have a very short prefix and a suffix I can expect to remember
2. Password for every website gets generated like this <prefix> + website name + <suffix>
3. Generate SHA256 hash of #2
4. Use #3 as password for the site.
5. Save password to password manager
Pros -
1. losing a password on one site doesn't compromise the pattern on others because cracking sha256 is still not possible (afaik)
2. relatively easy rules to create new password
3. If I HAVE to login on a computer without my password manager (e.g., public workstation), I can regenerate my password on the fly.
Cons -
1. I use an external sha-256 calculator
2. Some sites enforce password length and arbitrary case/symbols rules. Have to manipulate generated password by hand
1. This relies on a mistaken expectation that all sites you use being able to accept SHA256 output - presumably in Base64 or similar- as an acceptable password. You will likely have to compromise this.
2. You have no credential expiry built into this approach. Even should you decide to not use credential expiry, if one site demands it, your strategy doesn't work.
3. You are still at risk of having your passwords leak because: Anyone who compromises a public machine on which you generated your password manually (eg leaving any traces in logs, bash history etc) who eyeballs your SHA256 input prefix_ashleymadison.com_suffix , now has very clear reasons to expect they can generate passwords based on prefix_facebook.com_suffix and pre_barclaysbank.com_suffix because your credentials between sites are now not independent of each other, and worse, directly suggest each other.
Ignoring keyloggers and bash history issues etc any simple 'over the shoulder' attacker, likewise, get a pretty good guess at all of your passwords all at once by observing you generate a password for one site just once.
In short, if you attempt to use an approach like this, you no longer just have to protect your password, you have to absolutely protect the knowledge of the algorithm by which you generate your password for different sites. This being compromised just once potentially compromises all your passwords, substantially widening the ways in which you can be harmed.
At some point a site you use will be compromised, so you have a problem as that site will require a new password.
So your login routine is now:
* Generate your password via hash(prefix + sitename + suffix), and use it on every site, except that compromised one. Because it invalidated your old password and won't let you reuse it.
In short you have a versioning problem. And you have to remember it. The problem compounds for each site you use which insists upon a change for whatever reason.
(Also your own "con" - different sites have different restrictions/caveats for password formats.)
Use a password-manager, it really is the best way to have a unique and secure password for each site.
I do use my Mac's Keychain Access. My issue started when I had to use a work computer for logging into a newspaper account and I couldn't remember what it was because it was saved on my personal laptop. That's when I came up with this scheme.
> versioning problem
Someone else pointed this out as well. Thanks for thinking this thru.
I'm not sure what you are saying ... should I memorize dozens of passwords like WCLfx(edI%uHgjWM6RuEeC6Qh for the services I use or should I strap on getting those dozens of services to use a perfect SSO service that doesn't leak privacy and is perfectly secure and doesn't exist yet?
(And you do need to memorize your password manager password - and your main email account password as well)
Also a lot of leaked passwords were strong, they just got compromised because someone didn't know about 70's password security basics.
Should we just never use any leaked password ever again? (Note I'm not saying: with the same login - or any of the "top 100") Should we really trust all of our passwords to one service that might get compromised or just go away?
Should we bother creating a strong unique password for that new cool SF startup that doesn't know how to use bcrypt?
If it is well integrated with your browser it's quite ok. Maybe not as convenient as using the same simple password everywhere but certainly a lot better than having to remember a lot of different passwords ;)
I personally prefer _not_ integrating my password manager with my browser, even though the option is available. Instead my password manager performs manually-activated autotyping which, while less convenient, does at least 'feel' like it's more secure.
I trust my OS to isolate applications from eachother more than I trust my browser to isolate extensions from the page they run on. LastPass in particular have had their browser extension exploited[0].
But for this it is probably good that the services do fingerprint us - so that we understand how well it can work. Otherwise we'd assume that cleaning cookies is enough and wouldn't know how well that tracking works, not only when services that we knowingly use are doing it, but also when some actual black hats do it.
The idea is based on internal reflection: Whenever lights hits the boundary between two materials with different density it gets refracted. If it goes from dense to less dense and the angle is flat enough it will reflect back. This is the principle behind fibre optics. It's also the reason why the water's surface looks "silvery" (like a mirror) when you're submerged and look up at an angle (i.e. not straight up).
Now imagine you have a plane of glass and you put LEDs around the edges that shine into it from the side. The light will zig-zag trough the glass and come out at the other edge. However, if you touch the glass you inhibit that total internal reflection because your finger is alot denser than the air and so the light will "leak" out the glass where you touch it, illuminating your finger. If you look at the glass from behind you'll see a bright spot.
Use a camera to detect that spot and you basically have a touchpad. To make it a screen you can put a translucent sheet behind the glass and project an image onto it (and use infrared LEDs).
See e.g. http://wiki.nuigroup.com/FTIR for some helpful images. Just google "FTIR touch screen" or similar for build instructions and blob-detection software.