This may be overly cynical of me, but could they be doing this to imbue the sense of improved security, while still being able to decrypt and observe the traffic themselves? For themselves as well as for the government, where the particular datacenter is located?
How is encryption of data on-the-wire relevant to the observation of data stored in their datacenters?
Whether or not they use HTTPS, Google has always been able to access the content of Blogspot-hosted blogs because Google runs Blogspot and the data resides on their servers. Adding HTTPS doesn't change that at all.
Seriously. I'm 33 and HL2 came out when I was 21. I've got a nearly two-year-old daughter now, and I'm hoping that I'll be able to play HL3 sometime before she's old enough to play HL2.
Don't get me wrong: I love all the other Valve-produced games like the Portal series, Left 4 Dead, Team Fortress, etc., but there's a special place in my heart for the HL series.
Put simply, there exist plenty of systems and techniques that don't depend on a third-party who could possibly grant access to secure communications. These systems aren't going to disappear. Why would terrorists or other criminals use a system that could be monitored by authorities when secure alternatives exist? Why would ordinary people?
That's a really easy answer -- terrorists use these simple platforms for the same reason normal people do: because they're easy to use. Obviously a lot of our techniques and capabilities have been laid bare, but people use things like WhatsApp, iMessage, and Telegram because they're easy. It's the same reason that ordinary people -- and terrorists -- don't use Ello instead of Facebook, or ProtonMail instead of Gmail. And when people switch to more complicated, non-turnkey encryption solutions -- no matter how "simple" the more savvy may think them -- they make mistakes that can render their communications security measures vulnerable to defeat.
If the choice was between (easy & insecure) and (hard & secure), you'd have a point, but there's plenty of easy ways to have secure communication: for example, OTR-over-(any IM protocol) is about as simple as it gets (it's literally a one-click thing, and can be set to automatically go secure with no user interaction), doesn't depend on a provider for keys, and can work with any IM network. If someone can install an executable file, they can install and use OTR.
Sure, it doesn't conceal metadata, but most (all?) IM networks leak metadata as well. XMPP-over-Tor-hidden-service can help mask that, and isn't really complicated for the users ("Open Tor, click 'Connect' and wait for the green light, then open your IM client.").
Tox is another option: anonymous, distributed, and with no single point of failure. It's as easy to use as any other IM client.
Even if secure communications weren't as easy as non-secure methods, there's plenty of easy-to-follow guides on how to setup and use secure methods. It's hardly rocket science, and those methods aren't going away, so there's no reason to expect that bad guys that are motivated to keep their communications private will avoid them simply because they may be slightly more difficult.
I'm not saying that the vendors and cloud providers ALWAYS can provide assistance; but sometimes they can, given a particular target (device, email address, etc.), and they can do so in a way that comports with the rule of law in free society, doesn't require creating backdoors in encryption, and doesn't require "weakening" their products. And of course, it would be good if we were able to leverage certain things against legitimate foreign intelligence targets without the entire world knowing exactly what we are doing, so our enemies know exactly how to avoid it. Secrecy is required for the successful conduct of intelligence operations, even in free societies.
Sure, a company could do that (and several do), but there's certainly a lot of interest from users to have secure systems (devices, accounts, etc.) that cannot be remotely unlocked or decrypted by the company or authorities (see Apple). Considering how massively the US Government abused its position of power and authority through massive, warrantless surveillance of people, hacking and snooping corporate networks, doing shady things like parallel construction, and generally violating everyone's trust, it should come as no surprise that there's some pushback from users and industry.
Statistically, the risk posed by terrorists is so low as to not be a concern in my day-to-day life. I'm in far graver danger from occasionally eating hamburgers or riding a bike than I am from terrorists. Considering that "free societies" are hardly permanent things, and that a major event or political upset can dramatically change the nature of government, I'm more worried abo
The communication has to be decrypted somewhere; the endpoint(s) can be exploited in various ways. That can be done now. US vendors could, in theory, be at least a partial aid in that process on a device-by-device basis, within clear and specific legal authorities, without doing anything like key escrow, wholesale weakening of encryption, or similar with regard to software or devices themselves.
What if the endpoints aren't accessible to the vendors?
For example, one could easily exchange encrypted emails with a correspondent and not decrypt the messages on an internet-connected system. A Raspberry Pi is cheap and can easily act as a secure, offline system: the sender could write their sensitive messages on the offline system, encrypt them, transfer the encrypted messages to a USB stick, use the USB stick to transfer the message to an internet-connected computer, then email the encrypted message to the recipient who does the reverse.
Sure, it's an extra step compared to en/decrypting the message on the internet-connected system, but a relatively minor one.
Short of compromising the firmware on the USB stick (which is a possible, albeit non-trivial thing) or doing something extreme such as TEMPEST-type monitoring of the offline system, how would compromise such a system? Vendors would be unable to do anything to help authorities.
Alternatively, things like OTR can be overlaid on common protocols like XMPP, AIM, etc. but the keys are managed by the endpoints. The OTR software is not dependent on nor communicates with any "vendor" who could assist authorities. Same thing with other security software like GnuPG (which is developed in Germany, outside of US jurisdiction).
Put simply, there exist plenty of systems and techniques that don't depend on a third-party who could possibly grant access to secure communications. These systems aren't going to disappear. Why would terrorists or other criminals use a system that could be monitored by authorities when secure alternatives exist? Why would ordinary people?
I can't believe people would trust anything other than self signed certificates.
That's ridiculous. Anything you do with a self-signed certificate can also be done with a CA cert, including certificate/public key pinning. What you really mean is that you can't believe users trust browsers that don't do public key pinning.
Exactly. On my not-particularly-interesting sites, the CA-issued cert is used merely to (a) not show warnings in browsers and (b) offer an independent check on the legitimacy of my domain.
To prevent spoofing, I use DNSSEC+DANE to identify which certificates should be presented, as well as using HSTS to ensure future visits use TLS. I also use HPKP public key pinning.
All basic stuff that should be used by pretty much every secure site. Alas, it's not widely used. Too bad, really.
Huh? What? Cannot play videos? Damn. I missed that memo. I've been using Raspberry Pis as an in-car DVR for my kids for a few years now. Never had a problem. Straight from MythTV recorded mpeg4 onto a USB stick to playing on Raspberry PI. Just plug in the USB stick and give the kids a wireless mouse.
Proprietary bootloader? RaspBMC was so easy to set up, I'm afraid I never really noticed.
As someone with a toddler and a bunch of Pi2s, that sounds like a really nifty thing to do. Do you have any information about how you built it, what components are used, etc.?
Apologies: I mis-read the earlier comment. My comment about StartSSL generating a private key for the user applies only for SSL/TLS certs (where users can, as I mentioned, skip that and submit their own CSR).
When one generates a client certificate such as used in S/MIME, the key generation takes place entirely in the browser using keygen tags -- the private key is stored locally and the public key is sent to the server for signing.
Put simply, StartSSL (and other CAs around the world) are happy to issue certificates identifying you as you, but none of them AFAIK generate the private key themselves. Maybe some internal corporate CA systems do, but I'm not aware of any commercial ones that generate private keys for client certs.
Not necessary. Startcom, a company in Israel, is happy to generate and store a key that you can use to certify that you are you, for free. I think this also demonstrates the insane brokenness of the certificate authority system.
Sure, they offer the option (by default, which is annoying) for them to generate a private key for you (they claim not to store it) but you're welcome to generate your own private key and CSR and submit it for signing -- that way they never see your private key.
AC has far lower transmission losses over long distances
Does it? I was always under the impression that AC was used for long-distance transmission because it could be easily stepped up to very high voltages with transformers while efficient DC-to-DC conversion was not possible until relatively recently. For the same power transmitted, resistive losses are lower at higher voltages as power lost to heat goes as I^2*R and lower currents could be used.
However, modern solid-state DC-to-DC converters are extremely efficient, can step DC voltages up to very high voltages and thus benefit from lower resistive losses in transmission. HVDC also benefits from not having to deal with inductive or capacitive losses in the cable.
In short, as far I know the key to minimizing losses in transmission lines is to use high voltages, not because of any inherent advantage of AC.
I recently took a private tour of the time and frequency lab at METAS (the Swiss Federal Institute of Metrology) and got to observe their atomic clocks, ask the people there some questions, etc.
The scientist in charge of the lab wishes everyone would use TAI for time distribution. TAI has no leap seconds and differs from GPS time by a constant 19 seconds. If TAI was used, computers would never have to worry about leap seconds internally and things would be greatly simplified.
Computers don't care what time is used internally, and it's easy for computers to get a table of leap seconds and use that data to display UTC to users so the displayed time matches solar time.
Intel Core 2 Quad Q6600 @2.4GHz 8GB DDR2 RAM (MB can hold 16GB, but DDR2 is blood expensive now) Gigabyte GA-EP45-UD3R motherboard Nvidia GeForce GTX 550 Ti Crucial M550 1TB SSD (boot disk, most applications) Mixed SATA hard disks, from 750GB to 4TB (games, photos, backups, etc.)
Nothing special, but other than the graphics card and hard disks I've found no real need to upgrade the rest of the system. I built it back in 2007 with my then-girlfriend (now wife) and it just keeps on trucking along, plays modern games with no issues, etc.
Rather than take the time to understand their perimeter and data it exposes they want to "protect" everything with HTTPS. Which probably doesn't make sense for static, non interactive services.
Perhaps, but it also helps protect against content injection or manipulation (e.g. ad injection by shady ISPs), snooping by third parties (e.g. hotel or coffee-shop networks), etc.
Honestly, there's very little reason *not* to encrypt data these days.
How many people routinely check the source of their own web page through different connections to look for such injections? If some major US cell network or ISP did this, how likely they will be caught? Would https stop them from messing around with injections?
So long as the injector can't issue SSL certs that the user will trust, yes, https will stop such injections.
If the injector *can* issue SSL certs that the user will trust (e.g. the ISP requires users install their local CA, or they somehow have a global wildcard from a trusted CA), all bets are off -- the injector can impersonate and inject content into any https-secured site.
... have Facebook encrypt email it sends to you...
This doesn't prove who sent the message. A message must be encrypted with the receiver's public key and encrypted again with the sender's private key. Once again, all security depends on the integrity of the public-key server. Such servers can't prevent man-in-the-middle attacks.
In addition to encrypting messages to your public key, Facebook also digitally signs the messages using their private key and rotates the signing subkey every few months.
The fingerprint of their primary key (which is used to sign the signing subkeys) is available on their HTTPS-secured announcement page.
Additionally, all outgoing emails from Facebook are DKIM-signed, adding further assurance that it's from them.
Sure, it's *possible* that an HTTPS connection may be MITMed and DKIM records spoofed, but that requires an active attacker and significantly increases the risk of the attacker getting discovered. You could use Tor, a VPN, or a proxy from a different computer to verify that the HTTPS certificate, DKIM public keys, and the PGP fingerprint are what you see on your normal internet connection and thus have more assurance that the information is authentic.
That's not how it works. Facebook isn't letting you use PGP to encrypt user-to-user messages.
They're letting you upload your *public* key to your profile with the option to have Facebook encrypt any automated notification messages it sends to your email. This way those notification messages are protected from snooping as they traverse the internet between Facebook and your email server, while they are stored on the mail server, etc.
So how are you securely getting the email message to facebook to start with? I see an SSL connection that could easily have a "man in the middle" thing going on...
Facebook is encrypting automated notification messages (e.g. "[Friend name] posted new photos. Click here to see them." or "[Friend name] sent you a message on Facebook. Login to read it.") that it sends to your email account. Messages sent within Facebook are still unencrypted, only the notification message sent to your non-Facebook email would be encrypted.
Maybe you're right. But for me pgp encryption needs marketing so a lot of people start using or at least being aware of it. It needs to become mainstream.
Why not S/MIME? - Seems like a better technology to me, since you can encrypt entire MIME parts (including attachments and (some) headers) rather than just body text.
A PKI is required (or at least strongly encouraged, if users don't want to self-sign keys) for S/MIME. CA-issued keys typically cost money and expire at regular intervals. Outside of corporate environments with managed keyservers, S/MIME is quite uncommon. PGP is hardly common as it is, but it's likely more so than S/MIME.
Facebook can (and does) use PGP/MIME, which has the advantages of S/MIME that you mention while avoiding the downsides.
Uh, if Facebook is doing the encryption that means they have the unencrypted plaintext. How does Facebook encrypting the message on the last leg of its journey to you prevent the NSA from intercepting the plaintext anywhere else along the chain, including having access to Facebook's servers?
Encryption that isn't performed on your machine isn't useful encryption.
Not all adversaries have access (either through legal methods like subpoenas, or otherwise) to Facebook. As an example, a non-US government might be snooping on network connections or foreign mail servers, or they might subpoena those services to gain information on a user. Network providers might monitor user traffic for advertising or other purposes. Email services like Gmail can scan a user's messages to build up a profile or get information on a user.
Accessing Facebook over HTTPS provides protection from many of these adversaries. Nobody reasonably argues that accessing Facebook over plaintext is a good idea. This is the same principle extended to email.
Oh, I don't know. It seems to me they have a 100% success rate since 9/11. We haven't had a successful terrorist attack on an airport or airliner in the years following that tragedy. All the anti-government nitwits can kick and scream all they want, and invent excuses and reasons, but at the end of the day THIS PROGRAM HAS DONE ITS JOB. Mission accomplished. Unless you had some other criteria you want to judge them on. And they cannot continue to do it without occasionally brushing a hand where you may not normally have one (besides your own). Deal with it, or find another way to travel. My safety is not worth pandering to your psychological shortcomings.
How frequently did terrorist attacks (attempted or successful) against airliners take place in the US in the years leading up to 9/11, compared to afterwards? How does this compare to other countries with differing degrees of security at airports? (For example, in Zurich there's no body scanners. Just metal detectors and standard luggage x-ray machines.)
Have there been any other changes in regards to monitoring or detecting (potential) terrorists that might have had a bigger effect?
One could argue that current airport screening techniques are reasonable and justified. However, there's obviously unreasonable extremes which one could consider (e.g. full cavity searches for all passengers, requiring passengers to strip and wear only airline-supplied hospital-style gowns, etc.). Where does one draw the line? When does something become unreasonable and not worth doing even if it could increase safety?
They even once saved a plane from the pudding cup my daughter left in her backpack (which naturally earned her a pat-down).
My wife, then-infant daughter, and I had an interesting experience flying in the US: we often traveled with pre-packaged, ready-to-use UHT-sterilized bottles of formula just in case (a) my wife's milk production was insufficient at that moment and (b) we didn't have sufficient time or access to things like boiling water needed to make powdered formula. Since opening the sealed bottles defeats the point of UHT sterilization and starts the ~2 hour countdown after which the formula must be discarded, we asked them not to open the bottles.
Typically this was no problem: they did some swab tests, x-rayed the bottles, and concluded that they were (correctly) harmless. Additionally, they said that not opening the bottles meant that either my wife or I needed to get a pat-down but they let us choose who got the touchy-feely treatment. Obviously, any bad guys would have the one without concealed contraband get the search, thus defeating the purpose of the search.
At least that was better than Newark: the security screeners said they needed to do the swabbing and other tests before letting us proceed. However, the checkpoint was quite busy at the moment so they just had us stand around next to a table holding the bottles, my laptop, etc. for 10 minutes or so, then let us collect all the stuff and go. At no time were any of the tests they mentioned actually done.
Nope, SA is turned off even in war zones, in fact the newest birds don't even have the SA feature.
True, Selective Availability is disabled or otherwise not available on the new satellites, but the government still retains the ability to deny GPS on a regional basis.
"Why are you turning [SA] off? A. The decision to end the degradation of civil accuracy on a global level was made by the President based on a Secretary of Defense recommendation coordinated with all applicable departments and agencies. This decision is based on the U.S. military commitment to develop and employ technologies to deny the civil services of GPS on a regional basis. Under this approach, it will be possible to deny GPS to potential adversaries in areas of operations while preserving the peaceful use of GPS services outside those areas"
That said, civilian GPS receivers are often quite a bit better, more handy, and more advanced than military ones and a lot of soldiers use them in combat areas. Sure, the military ones are more rugged and get the encrypted military-only channel with better accuracy, but sub-meter accuracy is only really needed for smart bombs and the like. It's less useful for driving a Humvee down the street somewhere or finding out how to get back to base. Handheld civil GPS receivers are typically accurate down to the 3-5 meter range, which is only slightly worse than the military ones.
Denying civil GPS signals in certain regions would almost certainly make things worse for US soldiers, so it's extremely unlikely that the military would ever do regional denial of civil GPS except in the most extreme situations. Even then it'd have limited effect because GLONASS (Russian), Compass (Chinese), and Galileo (EU) are or will soon be perfectly viable alternatives that bad guys could use for guidance.
Especially compared to generating a gpg key that process is still a huge pain, requiring you to fiddle with obscure commands (seriously, the openssl command-line options read like someone sat down for half a year and thought "how can I make this as unusable as possible?"). Why isn't there a one-line program that does everything, ideally including submitting the request for signing? Plus a GUI of course, especially for Windows users.
Private keys for S/MIME certs ("client certs", more generally) are generated automatically in the browser, a CSR is generated and sent automatically to the CA for verification/signing. No command-line utilities are needed at all and the private key doesn't leave the browser. Quick, easy, and secure.
If you go through the process to get an S/MIME cert at StartSSL or other CAs, everything is handled seamlessly in the browser without the CA generating (or knowing) the private key.
Of course, StartSSL offers the function to generate the private key for *server* certs for you (which is stupid but convenient) by default but one can readily submit a CSR for signing in the normal way.
Although not the cheapest (a.com with NameCheap and whois protection costs $13.57/year. With Gandi it's $15.50), I find that you get what you pay for: for an extra ~$2/year or so you get clueful staff who respond promptly and competently to issues, built-in whois protection (lots of registrars charge extra for that) that ensures that you're still the legal owner of the domain (your name is listed as the registrant, but all the contact information can be masked with Gandi's information by the whois protection), the ability to add DS records for DNSSEC (neither NameCheap nor Hover allow this), a good API if you want to do things programmatically, and a great UI. You get a free SSL cert when you register/transfer in a domain, and SSL certs can be purchased from them (they chain up to Comodo) for a reasonable price.
They support a variety of organizations, including the EFF and Debian, that do good works on-line and off-.
Also, they're located in France. This offers some protection from various US shenanigans when it comes to seizing domains (assuming the TLD is not US-based), if that's something you're worried about. It's not perfect, of course, but it's something to keep in mind.
They offer decent, anycasted DNS service. Their nodes are located in Paris, Luxembourg, and Baltimore, so they have reasonable resolution speeds in Europe and North America. Nothing fancy, but it works well. You can, of course, use any other DNS host you want (e.g. one run by your web host, a third party service like easyDNS, etc.).
They also offer three types of hosting: basic web hosting, "Simple Hosting", and VPSs. The VPSs are pretty bog-standard, so you won't see any surprises, but I find DigitalOcean to be a better value for VPSs. The "Simple Hosting" is interesting to me, as it's a sort of crossover between shared hosting and a VPS: you choose what type of instance you want (PHP, Node.js, Python, or Ruby), what database type you want (MySQL, PgSQL, or MongoDB) and how much resources you need and you get a dedicated instance of that type. Instances are managed by a hypervisor so other users on the same hardware are logically separated and don't interfere with your service. Additionally, they put a Varnish cache server upstream of your instance so it's extremely fast.
Alternatively, I recommend NearlyFreeSpeech.net for excellent hosting.
In short: Gandi is a fine registrar and I strongly recommend them.
I've been using a CODE Keyboard for several months now. I really like it.
It's a mechanical keyboard using Cherry MX Clear switches, so it has a good tactile response without being super clicky. Certain settings can be changed using a DIP switch on the bottom. The keyboard uses a standard, detachable micro USB cable: cables have always been a weak spot on my keyboards, so it's nice to know I can replace it if needed.
The keys are mounted on a steel plate (not as heavy as the Model M, though) so they keyboard feels very solid.
Slashdot Mirror
This may be overly cynical of me, but could they be doing this to imbue the sense of improved security, while still being able to decrypt and observe the traffic themselves? For themselves as well as for the government, where the particular datacenter is located?
How is encryption of data on-the-wire relevant to the observation of data stored in their datacenters?
Whether or not they use HTTPS, Google has always been able to access the content of Blogspot-hosted blogs because Google runs Blogspot and the data resides on their servers. Adding HTTPS doesn't change that at all.
Seriously. I'm 33 and HL2 came out when I was 21. I've got a nearly two-year-old daughter now, and I'm hoping that I'll be able to play HL3 sometime before she's old enough to play HL2.
Don't get me wrong: I love all the other Valve-produced games like the Portal series, Left 4 Dead, Team Fortress, etc., but there's a special place in my heart for the HL series.
Put simply, there exist plenty of systems and techniques that don't depend on a third-party who could possibly grant access to secure communications. These systems aren't going to disappear. Why would terrorists or other criminals use a system that could be monitored by authorities when secure alternatives exist? Why would ordinary people?
That's a really easy answer -- terrorists use these simple platforms for the same reason normal people do: because they're easy to use. Obviously a lot of our techniques and capabilities have been laid bare, but people use things like WhatsApp, iMessage, and Telegram because they're easy. It's the same reason that ordinary people -- and terrorists -- don't use Ello instead of Facebook, or ProtonMail instead of Gmail. And when people switch to more complicated, non-turnkey encryption solutions -- no matter how "simple" the more savvy may think them -- they make mistakes that can render their communications security measures vulnerable to defeat.
If the choice was between (easy & insecure) and (hard & secure), you'd have a point, but there's plenty of easy ways to have secure communication: for example, OTR-over-(any IM protocol) is about as simple as it gets (it's literally a one-click thing, and can be set to automatically go secure with no user interaction), doesn't depend on a provider for keys, and can work with any IM network. If someone can install an executable file, they can install and use OTR.
Sure, it doesn't conceal metadata, but most (all?) IM networks leak metadata as well. XMPP-over-Tor-hidden-service can help mask that, and isn't really complicated for the users ("Open Tor, click 'Connect' and wait for the green light, then open your IM client.").
Tox is another option: anonymous, distributed, and with no single point of failure. It's as easy to use as any other IM client.
Even if secure communications weren't as easy as non-secure methods, there's plenty of easy-to-follow guides on how to setup and use secure methods. It's hardly rocket science, and those methods aren't going away, so there's no reason to expect that bad guys that are motivated to keep their communications private will avoid them simply because they may be slightly more difficult.
I'm not saying that the vendors and cloud providers ALWAYS can provide assistance; but sometimes they can, given a particular target (device, email address, etc.), and they can do so in a way that comports with the rule of law in free society, doesn't require creating backdoors in encryption, and doesn't require "weakening" their products. And of course, it would be good if we were able to leverage certain things against legitimate foreign intelligence targets without the entire world knowing exactly what we are doing, so our enemies know exactly how to avoid it. Secrecy is required for the successful conduct of intelligence operations, even in free societies.
Sure, a company could do that (and several do), but there's certainly a lot of interest from users to have secure systems (devices, accounts, etc.) that cannot be remotely unlocked or decrypted by the company or authorities (see Apple). Considering how massively the US Government abused its position of power and authority through massive, warrantless surveillance of people, hacking and snooping corporate networks, doing shady things like parallel construction, and generally violating everyone's trust, it should come as no surprise that there's some pushback from users and industry.
Statistically, the risk posed by terrorists is so low as to not be a concern in my day-to-day life. I'm in far graver danger from occasionally eating hamburgers or riding a bike than I am from terrorists. Considering that "free societies" are hardly permanent things, and that a major event or political upset can dramatically change the nature of government, I'm more worried abo
Sure. One hypothetical example:
The communication has to be decrypted somewhere; the endpoint(s) can be exploited in various ways. That can be done now. US vendors could, in theory, be at least a partial aid in that process on a device-by-device basis, within clear and specific legal authorities, without doing anything like key escrow, wholesale weakening of encryption, or similar with regard to software or devices themselves.
What if the endpoints aren't accessible to the vendors?
For example, one could easily exchange encrypted emails with a correspondent and not decrypt the messages on an internet-connected system. A Raspberry Pi is cheap and can easily act as a secure, offline system: the sender could write their sensitive messages on the offline system, encrypt them, transfer the encrypted messages to a USB stick, use the USB stick to transfer the message to an internet-connected computer, then email the encrypted message to the recipient who does the reverse.
Sure, it's an extra step compared to en/decrypting the message on the internet-connected system, but a relatively minor one.
Short of compromising the firmware on the USB stick (which is a possible, albeit non-trivial thing) or doing something extreme such as TEMPEST-type monitoring of the offline system, how would compromise such a system? Vendors would be unable to do anything to help authorities.
Alternatively, things like OTR can be overlaid on common protocols like XMPP, AIM, etc. but the keys are managed by the endpoints. The OTR software is not dependent on nor communicates with any "vendor" who could assist authorities. Same thing with other security software like GnuPG (which is developed in Germany, outside of US jurisdiction).
Put simply, there exist plenty of systems and techniques that don't depend on a third-party who could possibly grant access to secure communications. These systems aren't going to disappear. Why would terrorists or other criminals use a system that could be monitored by authorities when secure alternatives exist? Why would ordinary people?
That's ridiculous. Anything you do with a self-signed certificate can also be done with a CA cert, including certificate/public key pinning. What you really mean is that you can't believe users trust browsers that don't do public key pinning.
Exactly. On my not-particularly-interesting sites, the CA-issued cert is used merely to (a) not show warnings in browsers and (b) offer an independent check on the legitimacy of my domain.
To prevent spoofing, I use DNSSEC+DANE to identify which certificates should be presented, as well as using HSTS to ensure future visits use TLS. I also use HPKP public key pinning.
All basic stuff that should be used by pretty much every secure site. Alas, it's not widely used. Too bad, really.
Huh? What? Cannot play videos? Damn. I missed that memo. I've been using Raspberry Pis as an in-car DVR for my kids for a few years now. Never had a problem. Straight from MythTV recorded mpeg4 onto a USB stick to playing on Raspberry PI. Just plug in the USB stick and give the kids a wireless mouse.
Proprietary bootloader? RaspBMC was so easy to set up, I'm afraid I never really noticed.
As someone with a toddler and a bunch of Pi2s, that sounds like a really nifty thing to do. Do you have any information about how you built it, what components are used, etc.?
Apologies: I mis-read the earlier comment. My comment about StartSSL generating a private key for the user applies only for SSL/TLS certs (where users can, as I mentioned, skip that and submit their own CSR).
When one generates a client certificate such as used in S/MIME, the key generation takes place entirely in the browser using keygen tags -- the private key is stored locally and the public key is sent to the server for signing.
Put simply, StartSSL (and other CAs around the world) are happy to issue certificates identifying you as you, but none of them AFAIK generate the private key themselves. Maybe some internal corporate CA systems do, but I'm not aware of any commercial ones that generate private keys for client certs.
Not necessary. Startcom, a company in Israel, is happy to generate and store a key that you can use to certify that you are you, for free. I think this also demonstrates the insane brokenness of the certificate authority system.
Sure, they offer the option (by default, which is annoying) for them to generate a private key for you (they claim not to store it) but you're welcome to generate your own private key and CSR and submit it for signing -- that way they never see your private key.
AC has far lower transmission losses over long distances
Does it? I was always under the impression that AC was used for long-distance transmission because it could be easily stepped up to very high voltages with transformers while efficient DC-to-DC conversion was not possible until relatively recently. For the same power transmitted, resistive losses are lower at higher voltages as power lost to heat goes as I^2*R and lower currents could be used.
However, modern solid-state DC-to-DC converters are extremely efficient, can step DC voltages up to very high voltages and thus benefit from lower resistive losses in transmission. HVDC also benefits from not having to deal with inductive or capacitive losses in the cable.
In short, as far I know the key to minimizing losses in transmission lines is to use high voltages, not because of any inherent advantage of AC.
I recently took a private tour of the time and frequency lab at METAS (the Swiss Federal Institute of Metrology) and got to observe their atomic clocks, ask the people there some questions, etc.
The scientist in charge of the lab wishes everyone would use TAI for time distribution. TAI has no leap seconds and differs from GPS time by a constant 19 seconds. If TAI was used, computers would never have to worry about leap seconds internally and things would be greatly simplified.
Computers don't care what time is used internally, and it's easy for computers to get a table of leap seconds and use that data to display UTC to users so the displayed time matches solar time.
My desktop at home has the following:
Intel Core 2 Quad Q6600 @2.4GHz
8GB DDR2 RAM (MB can hold 16GB, but DDR2 is blood expensive now)
Gigabyte GA-EP45-UD3R motherboard
Nvidia GeForce GTX 550 Ti
Crucial M550 1TB SSD (boot disk, most applications)
Mixed SATA hard disks, from 750GB to 4TB (games, photos, backups, etc.)
Nothing special, but other than the graphics card and hard disks I've found no real need to upgrade the rest of the system. I built it back in 2007 with my then-girlfriend (now wife) and it just keeps on trucking along, plays modern games with no issues, etc.
Rather than take the time to understand their perimeter and data it exposes they want to "protect" everything with HTTPS. Which probably doesn't make sense for static, non interactive services.
Perhaps, but it also helps protect against content injection or manipulation (e.g. ad injection by shady ISPs), snooping by third parties (e.g. hotel or coffee-shop networks), etc.
Honestly, there's very little reason *not* to encrypt data these days.
How many people routinely check the source of their own web page through different connections to look for such injections? If some major US cell network or ISP did this, how likely they will be caught? Would https stop them from messing around with injections?
So long as the injector can't issue SSL certs that the user will trust, yes, https will stop such injections.
If the injector *can* issue SSL certs that the user will trust (e.g. the ISP requires users install their local CA, or they somehow have a global wildcard from a trusted CA), all bets are off -- the injector can impersonate and inject content into any https-secured site.
This doesn't prove who sent the message. A message must be encrypted with the receiver's public key and encrypted again with the sender's private key. Once again, all security depends on the integrity of the public-key server. Such servers can't prevent man-in-the-middle attacks.
In addition to encrypting messages to your public key, Facebook also digitally signs the messages using their private key and rotates the signing subkey every few months.
The fingerprint of their primary key (which is used to sign the signing subkeys) is available on their HTTPS-secured announcement page.
Additionally, all outgoing emails from Facebook are DKIM-signed, adding further assurance that it's from them.
Sure, it's *possible* that an HTTPS connection may be MITMed and DKIM records spoofed, but that requires an active attacker and significantly increases the risk of the attacker getting discovered. You could use Tor, a VPN, or a proxy from a different computer to verify that the HTTPS certificate, DKIM public keys, and the PGP fingerprint are what you see on your normal internet connection and thus have more assurance that the information is authentic.
That's not how it works. Facebook isn't letting you use PGP to encrypt user-to-user messages.
They're letting you upload your *public* key to your profile with the option to have Facebook encrypt any automated notification messages it sends to your email. This way those notification messages are protected from snooping as they traverse the internet between Facebook and your email server, while they are stored on the mail server, etc.
I'm wondering how they encode the messages, do they use PGP Inline or PGP/MIME? Has anybody tried it and can comment on that?
I'm using it. They use PGP/MIME.
So how are you securely getting the email message to facebook to start with? I see an SSL connection that could easily have a "man in the middle" thing going on...
Facebook is encrypting automated notification messages (e.g. "[Friend name] posted new photos. Click here to see them." or "[Friend name] sent you a message on Facebook. Login to read it.") that it sends to your email account. Messages sent within Facebook are still unencrypted, only the notification message sent to your non-Facebook email would be encrypted.
Maybe you're right. But for me pgp encryption needs marketing so a lot of people start using or at least being aware of it. It needs to become mainstream.
Why not S/MIME? - Seems like a better technology to me, since you can encrypt entire MIME parts (including attachments and (some) headers) rather than just body text.
A PKI is required (or at least strongly encouraged, if users don't want to self-sign keys) for S/MIME. CA-issued keys typically cost money and expire at regular intervals. Outside of corporate environments with managed keyservers, S/MIME is quite uncommon. PGP is hardly common as it is, but it's likely more so than S/MIME.
Facebook can (and does) use PGP/MIME, which has the advantages of S/MIME that you mention while avoiding the downsides.
Uh, if Facebook is doing the encryption that means they have the unencrypted plaintext. How does Facebook encrypting the message on the last leg of its journey to you prevent the NSA from intercepting the plaintext anywhere else along the chain, including having access to Facebook's servers?
Encryption that isn't performed on your machine isn't useful encryption.
Not all adversaries have access (either through legal methods like subpoenas, or otherwise) to Facebook. As an example, a non-US government might be snooping on network connections or foreign mail servers, or they might subpoena those services to gain information on a user. Network providers might monitor user traffic for advertising or other purposes. Email services like Gmail can scan a user's messages to build up a profile or get information on a user.
Accessing Facebook over HTTPS provides protection from many of these adversaries. Nobody reasonably argues that accessing Facebook over plaintext is a good idea. This is the same principle extended to email.
Oh, I don't know. It seems to me they have a 100% success rate since 9/11. We haven't had a successful terrorist attack on an airport or airliner in the years following that tragedy. All the anti-government nitwits can kick and scream all they want, and invent excuses and reasons, but at the end of the day THIS PROGRAM HAS DONE ITS JOB. Mission accomplished. Unless you had some other criteria you want to judge them on. And they cannot continue to do it without occasionally brushing a hand where you may not normally have one (besides your own). Deal with it, or find another way to travel. My safety is not worth pandering to your psychological shortcomings.
How frequently did terrorist attacks (attempted or successful) against airliners take place in the US in the years leading up to 9/11, compared to afterwards? How does this compare to other countries with differing degrees of security at airports? (For example, in Zurich there's no body scanners. Just metal detectors and standard luggage x-ray machines.)
Have there been any other changes in regards to monitoring or detecting (potential) terrorists that might have had a bigger effect?
One could argue that current airport screening techniques are reasonable and justified. However, there's obviously unreasonable extremes which one could consider (e.g. full cavity searches for all passengers, requiring passengers to strip and wear only airline-supplied hospital-style gowns, etc.). Where does one draw the line? When does something become unreasonable and not worth doing even if it could increase safety?
They even once saved a plane from the pudding cup my daughter left in her backpack (which naturally earned her a pat-down).
My wife, then-infant daughter, and I had an interesting experience flying in the US: we often traveled with pre-packaged, ready-to-use UHT-sterilized bottles of formula just in case (a) my wife's milk production was insufficient at that moment and (b) we didn't have sufficient time or access to things like boiling water needed to make powdered formula. Since opening the sealed bottles defeats the point of UHT sterilization and starts the ~2 hour countdown after which the formula must be discarded, we asked them not to open the bottles.
Typically this was no problem: they did some swab tests, x-rayed the bottles, and concluded that they were (correctly) harmless. Additionally, they said that not opening the bottles meant that either my wife or I needed to get a pat-down but they let us choose who got the touchy-feely treatment. Obviously, any bad guys would have the one without concealed contraband get the search, thus defeating the purpose of the search.
At least that was better than Newark: the security screeners said they needed to do the swabbing and other tests before letting us proceed. However, the checkpoint was quite busy at the moment so they just had us stand around next to a table holding the bottles, my laptop, etc. for 10 minutes or so, then let us collect all the stuff and go. At no time were any of the tests they mentioned actually done.
Nope, SA is turned off even in war zones, in fact the newest birds don't even have the SA feature.
True, Selective Availability is disabled or otherwise not available on the new satellites, but the government still retains the ability to deny GPS on a regional basis.
See :
"Why are you turning [SA] off?
A. The decision to end the degradation of civil accuracy on a global level was made by the President based on a Secretary of Defense recommendation coordinated with all applicable departments and agencies. This decision is based on the U.S. military commitment to develop and employ technologies to deny the civil services of GPS on a regional basis. Under this approach, it will be possible to deny GPS to potential adversaries in areas of operations while preserving the peaceful use of GPS services outside those areas"
That said, civilian GPS receivers are often quite a bit better, more handy, and more advanced than military ones and a lot of soldiers use them in combat areas. Sure, the military ones are more rugged and get the encrypted military-only channel with better accuracy, but sub-meter accuracy is only really needed for smart bombs and the like. It's less useful for driving a Humvee down the street somewhere or finding out how to get back to base. Handheld civil GPS receivers are typically accurate down to the 3-5 meter range, which is only slightly worse than the military ones.
Denying civil GPS signals in certain regions would almost certainly make things worse for US soldiers, so it's extremely unlikely that the military would ever do regional denial of civil GPS except in the most extreme situations. Even then it'd have limited effect because GLONASS (Russian), Compass (Chinese), and Galileo (EU) are or will soon be perfectly viable alternatives that bad guys could use for guidance.
Especially compared to generating a gpg key that process is still a huge pain, requiring you to fiddle with obscure commands (seriously, the openssl command-line options read like someone sat down for half a year and thought "how can I make this as unusable as possible?").
Why isn't there a one-line program that does everything, ideally including submitting the request for signing? Plus a GUI of course, especially for Windows users.
Private keys for S/MIME certs ("client certs", more generally) are generated automatically in the browser, a CSR is generated and sent automatically to the CA for verification/signing. No command-line utilities are needed at all and the private key doesn't leave the browser. Quick, easy, and secure.
If you go through the process to get an S/MIME cert at StartSSL or other CAs, everything is handled seamlessly in the browser without the CA generating (or knowing) the private key.
Of course, StartSSL offers the function to generate the private key for *server* certs for you (which is stupid but convenient) by default but one can readily submit a CSR for signing in the normal way.
Highly recommend gandi.net
Agreed.
Although not the cheapest (a .com with NameCheap and whois protection costs $13.57/year. With Gandi it's $15.50), I find that you get what you pay for: for an extra ~$2/year or so you get clueful staff who respond promptly and competently to issues, built-in whois protection (lots of registrars charge extra for that) that ensures that you're still the legal owner of the domain (your name is listed as the registrant, but all the contact information can be masked with Gandi's information by the whois protection), the ability to add DS records for DNSSEC (neither NameCheap nor Hover allow this), a good API if you want to do things programmatically, and a great UI. You get a free SSL cert when you register/transfer in a domain, and SSL certs can be purchased from them (they chain up to Comodo) for a reasonable price.
They support a variety of organizations, including the EFF and Debian, that do good works on-line and off-.
Also, they're located in France. This offers some protection from various US shenanigans when it comes to seizing domains (assuming the TLD is not US-based), if that's something you're worried about. It's not perfect, of course, but it's something to keep in mind.
They offer decent, anycasted DNS service. Their nodes are located in Paris, Luxembourg, and Baltimore, so they have reasonable resolution speeds in Europe and North America. Nothing fancy, but it works well. You can, of course, use any other DNS host you want (e.g. one run by your web host, a third party service like easyDNS, etc.).
They also offer three types of hosting: basic web hosting, "Simple Hosting", and VPSs. The VPSs are pretty bog-standard, so you won't see any surprises, but I find DigitalOcean to be a better value for VPSs. The "Simple Hosting" is interesting to me, as it's a sort of crossover between shared hosting and a VPS: you choose what type of instance you want (PHP, Node.js, Python, or Ruby), what database type you want (MySQL, PgSQL, or MongoDB) and how much resources you need and you get a dedicated instance of that type. Instances are managed by a hypervisor so other users on the same hardware are logically separated and don't interfere with your service. Additionally, they put a Varnish cache server upstream of your instance so it's extremely fast.
Alternatively, I recommend NearlyFreeSpeech.net for excellent hosting.
In short: Gandi is a fine registrar and I strongly recommend them.
I've been using a CODE Keyboard for several months now. I really like it.
It's a mechanical keyboard using Cherry MX Clear switches, so it has a good tactile response without being super clicky. Certain settings can be changed using a DIP switch on the bottom. The keyboard uses a standard, detachable micro USB cable: cables have always been a weak spot on my keyboards, so it's nice to know I can replace it if needed.
The keys are mounted on a steel plate (not as heavy as the Model M, though) so they keyboard feels very solid.