It used to be possible to run your own SMTP server, inbound and outbound, from home. This was so badly abused by spam that port 25 is blocked almost everywhere.
Domestic systems tend to be in configurations that make it hard to accept inbound TCP connections. You could serve SSL on a random port and open a port using UPNP, and it will work most of the time.
It's a difficult circle to square. The most trustworthy system is one you administer yourself and manually inspect all updates, but in practice the amount of work required makes that almost impossible. If you allow the OEM to do updates they can compromise you. If you don't do updates you end up vulnerable to exploits.
Even if your home provider allows you to accept SMTP on port 25, you're going to have a hell of a hard time with outbound delivery. The big mail providers give very low reputation ranking to e-mails originating from consumer connections. Even commercial connections w/ hosting providers need to be "warmed up" for a period of time to get their sending reputation to an appropriate level where they can expect reliable delivery without automatic spam-boxing.
What I'd rather see is a company go into partnership with the big providers to certify individual senders at home. The idea is that you'd put up some kind of bond (a few hundred USD?) to help ensure that you won't be sending spam. In exchange for your bond, the company vouches for your IP to Google/Yahoo/Hotmail/etc and you're allowed to send your own email. After some period of use w/o any spam complaints, you get your bond money back.
Despite my grievance elsewhere in this thread that mail servers do not come pre-configured with sensible defaults, I would guess that no modern mail servers are pre-configured as an open-relay when installed. The concern about port 25 relaying being abused by spammers strikes me as an anachronism.
In any event, I found that mainstream ISPs are willing to unblock port 25 if you tell them you are running a personal mail server and have it properly configured to not relay for unauthenticated users.
Aside from that, you'll want one static IP to make your life easy so you don't need to use dynamic DNS.
I think matters such as availability of your server and configuration are surmountable challenges.
But I strongly agree with you about security. Although I really like the idea of this device, the first thing I noticed in the product web page is the use of PHP Roundcube for webmail. I have a fear of running PHP anywhere on my network. The track record [1] is way better than, say, Wordpress, but seeing things like Exec Code, even back in 2008, gives me pause.
I remember reading some early RFC's that suggested pre-SMTP, remote "email" was "sent" using FTP.
Perhaps it was something like a PUT command to append to a user's "mail" file on the recipient computer?
This seems to suggest email was always envisioned as something to be "received" rather that voluntarily "retrieved".
In retrospect, knowing what happened to email, the later idea (e.g., djb's proposal) makes more sense.
The funny part is that even though the "receive" idea is still the core part of the email process, that is not what email users do in practice.
Users "retrieve" their mail from some third party who receives it for them.
First there was "POP" then there was "webmail".
Back in the Stone Age when email was "invented" computers were too expensive for the users to own.
Each user shared the computer with other users.
Each had an email account, usually administered by the organization that owned the expensive computer.
Today computers are inexpensive and seemingly all users own one but they still do not have control of their email accounts.
Some organization is still receiving all their mail before they do. And keeping a copy of course. :)
Then, in more recent history, the domain name "business" (a monopoly run by an organization that derives its "authority" from nowhere), fueled by the popularity of the "www", became the gatekeeper to email.
When was the last time you sent an email to user@[ipaddr]? Originally if my memory of the old RFC's is correct that was how it worked. No domain name needed.
Today, if there is no purchased, monopoly-blessed "domain name", then according to the people who control users' email there is no "valid" email address. No pay, no play. Even if port 25 is open.
Assuming a user who has paid for access to the "internet" wants control of their own email (seems reasonable), then "email" is still an addtional fee.
Back in the 90s, I used to run my own. It was extremely frustrating when big ISPs started blocking mail from dynamic addresses. I understand why they had to do it but it was still inconvenient for people like me.
port 25 blocking is just the beginning. In most cases mail sent from a consumer facing ISP (Verizon, AT&T, RCN, etc) will not be accepted if the destination server is implementing SPF mail authorization, which most are these days.
This looks very similar to what we built one year ago at https://kinko.me. And then we even managed to solve most of the problems outlined in the comments here (Port 25 blocked, etc.) But our crowdfunding campaign failed, and I have seen other campaigns with similar topics and target audiences fail since.
Consequently I doubt that a relevant audience for that type of device really exist -- even though I wished own-mailbox would succeed.
How does transmitting an HTTPS link solve email encryption for people who don't have PGP? The link is sent plaintext. Does the system require users to register out-of-band somehow? That's how corporate email "encryption" systems work (the "send an HTTPS link" approach is popular with financial firms).
The underlying approach this system uses --- webmail, but on a special purpose box the user owns --- is actually sound. It seems like a pretty good refinement of Mailpile.
On the other hand, they should tone the rhetoric down. I winced at "100% secure".
There are several options, ranging from making the link one-time only to requiring a captcha or password.
From TFA:
➜Can you explain more in details how Private Link Message (PLM) works?
Private Link Message (PLM) allows you to send and receive messages from people who don't use GPG.
The link is temporary: once clicked by your correspondent it is too late to spy, the link does not work anymore.
You can also, optionaly, setup an expiration date for the link. If your correspondent did not access the message before this date, it is too late to read.
The link is filtered by a question. Depending on the level of surveillance you think you are in, the question can be a simple captcha to avoid bots, a secret question that your correspondent can answer but not the NSA, or a request for a password previously exchanged with your correspondent, or no question at all.
Your correspondent will have a web interface to answer your message privately. You can also activate a permanent HTTPS interface for anyone to send you a message privately at any time.
In practice a simple captcha will allow you to be safe from mass surveillance, since only targeted surveillance can be done by human beings. On top of that any spy will be detected, and have his IP address revealed. On our test, no PLM has ever been spyed even with no question at all.
> The link is filtered by a question. Depending on the level of surveillance you think you are in, the question can be a simple captcha to avoid bots, a secret question that your correspondent can answer but not the NSA, or a request for a password previously exchanged with your correspondent, or no question at all.
> Your correspondent will have a web interface to answer your message privately. You can also activate a permanent HTTPS interface for anyone to send you a message privately at any time.
Granted, 100% secure is a bold claim, but it's not just an HTTPS link anyone can click on, at least not if you're a tiny bit clever enough to enable additional protection it offers.
But financial companies make sure to handle mail retention/archival, as well.
As I already said last time this product came up: this is not email. As far as encryption is concerned, it's a proprietary messenger, and it deprives not only the user (who opted in), but all of his recipients of virtually every advantage, standard email has got.
The reason for SMTP servers being better off in a proper data-center is not really due to port 25 being blocked at home, it's the entire infrastructure that assures reliability, so if your power goes out or your home router decides to die or your ISP is having issues, etc, you would start losing emails right away.
EDIT: I understand SMTPs are resilient but it also depends on the type of error they get back, even then it can't be expected that all servers keep retrying for long periods of time or even handle triple bounces.
So you 'could' start losing emails right away, is a better way of saying it.
Isn't SMTP actually pretty resilient to outages? Typically sending mail servers will retry for hours (or even days) before giving up when a recipient server is down.
This is somewhat mitigated by the fact that legitimate sending mail servers will retry delivery if the destination server is unavailable. Outbound mail from a home connection may very well have issues being marked as spam due to ip blacklists though.
RFCs dictate that a mail server retry sending when the MX host is unavailable. If the sending mail server doesn't retry then it is the sender's fault if a message is returned undeliverable without retrying at least a few times.
The "de facto standard" for retrying was (is?) five days, because that's what sendmail defaulted to for years. Nowadays, many senders don't retry that long (my mail systems are set for 48 hours) simply so that a bounce/undeliverable mail is returned to the sender much sooner.
IIRC, there was a certain version of Exchange (I forget which now) that apparently didn't retry and would immediately bounce a message if it was undeliverable on the first attempt, but that was quickly fixed.
eh, it's a security vs. reliability issue. You are right that a home-hosted email is going to be less reliable. Others are right that SMTP is pretty resilient, but not infinitely so.
A home mail server, from experience and from the experiences of others, would work okay on receive. You want a static IP (or a static-IP VPN.) at a minimum, and the first thing you need is to make sure you aren't on the dialup-user lists. But that's an outgoing mail issue, not an incoming mail issue.
that's the thing, though, the outgoing mail issue, ultimately, is more difficult than the incoming mail issue.
It isn't only receiving emails that requires a connection. According to the site, anyone who doesn't use encryption (currently the vast majority of users) will receive a link to your message hosted on the device. That means that most people won't be able to read your emails if your device goes offline.
Plus many spam blacklists have blacklisted entire IPv4 ranges as "residential IPs" (meaning even if your ISP does allow SMTP (which many do not) then your emails may still be blocked as "spam.").
Only way around all of this is to pay for a "business" internet connection (with 500% markup for the same speed, single dedicated IP, and a pretty poor SLA).
"Many ISP's" don't actually block 25/TCP outbound but simply add their residential netblocks to, e.g., the Spamhaus PBL. An end-user assigned one of these IPs can, upon request, have it removed from the PBL himself. This is, IMO, a much better way of "disallowing" outbound SMTP than simply filtering out packets.
In this case, this isn't necessarily needed as own-mailbox could be the MX and then transmit the data using some other protocol or even just SMTP over a different port.
Of course this means that they could read your email again, so we'd be back to square one.
But they tend to allow you to send and receive SMTP though their servers so for a thing like this there is only a potential problem with the web and IMAP part ... which can be solved with a VPN.
A couple of problems as noted already that will make this a show stopper:
> Port 25 is blocked inbound on most residential accounts - preventing you from receiving email
> Many SMTP servers are configured to automatically bounce email from residential IPs - so sending would be a problem
The point of GPG is to make sure that the only person that can read the message is the one you sent it to. Having a HTTPS site doesn't prevent the random person from viewing the link and doesn't verify the user. Now - this might be interesting if the web app that shows the email has as GPG library in Javascript requiring the user to have GPG keys.
I think a better scenario is if keys haven't been exchanged - to send an email with "Alice would like to communicate over secure email - please download and generate a set of keys" with instructions on what to do. But I have no idea how not to make it look spammy.
This is just hilarious:
> Why shouldn't I trust and use any cloud email service with JavaScript client-side encryption?
> Encryption is done in JavaScript, and therefore relies on browser's JavaScript engines, which 80% of the time [1] are proprietary software coming from Google, Microsoft, and Apple, most eminent NSA collaborators.
The author does know that Chrome is open source right (well I guess technically Chromium but I hope it's based on the same code)?
> Why not use a raspberry Pi?
> Mainly because it cannot be trusted enough for this kind of application. [...] The Raspberry pi is provided with non-free software and the hardware needs non-free driver to work.
I've used Debian Linux on it before and didn't need to install third party drivers?
* Reliability of ones Internet connection should not be much of an issue, because SMTP servers should retry to deliver a mail for several hours/days. Otherwise a secondary MX could be used as a backup for mails in transit.
* Policies of ones ISP are often a problem for something like this, you likely need a "business connection" for something like this.
* Dynamic DNS could be used for receiving, but you won't have much success in sending mails unless you have reverse DNS working and that requires a static IP as far as i know. Most users will only get a static IP for "business connections".
* I'd be really interested how the combine their usage of GPG with multiple client. Is there some sort of key management included? How does it work with Webmail/Roundcube? Is the same key used for desktop and mobile phones?
From the front page: "Optional P2P backup, so even if your Own-Mailbox is offline temporarily you don't lose any email from your self-hosted addresses as long as you maintain 70% up ratio." and "16GB storage, possibility to extend memory or do backup via USB drive/HDD."
If you use an IMAP client, you have a local backup. Alternatively, even if you exclusively use Webmail, you can still maintain a remote backup (using imapsync or similar). There's also the "optional P2P backup".
Its main feature is security, which is great for paranoid people. But what happens when you are miles away from home and your internet connections to the server goes down? How are you going to check your e-mail?
If you're concerned about privacy, it seems the best method is still to cut-and-paste encrypted envelope into regular mail client to avoid possible vulnerabilities, both physical and software. The obvious problem with a self-hosted server that you order from a company is that it can be intercepted or otherwise compromised before it arrives at your home. Thus it is potentially even more vulnerable than just pasting GPG encrypted message directly into gmail client.
> What about SSL certificates and authorities for HTTPS?
> Each Own-Mailbox will generate automatically its SSL key at first setup, and send to us the public part.
> Letsencrypt Certification Authority will be used , it is free and very easy to setup, and it will be handled automatically by your Own-Mailbox. Every Own-Mailbox will automatically ask for certification for its key indepently from us.
Regarding hardware-assisted self hosting, there is http://internetcu.be which, among other things, does email (and bypasses ISPs restrictions by bundling the "box" with a VPN and providing static IPv4 and 6 addresses to each user).
It's some sort of "freedombox" [0] come true. It works out of the box, in a plug and play fashion (and it's based on free hardware [1] and free software [2]).
The funny thing that most people who obsess over encryption forget is that using tough encryption attracts attention, and all the encryption in the world won't save you from simple workarounds (https://xkcd.com/538/) and ordinary surveillance.
The solution for all of us is to make ordinary communication more expensive to break into rather than to go out on a limb with attention-getting extraordinary measures.
I'd also have to say -- no offense intended -- that what I take to be a central European accented voice-over advocating using a new security product to avoid NSA surveillance doesn't fill me with confidence. I'm pretty sure the NSA is at least well-intentioned.
I'd suggest your best pitch accent would be scandinavian or perhaps Australian (not that the Australian government isn't horrible, but it's pretty harmless).
How are they going to receive mail? All blocks of IP's from any provider are blocked, usually huge blocks, larger than /24 often. No one is getting to any comcast users, they as do many others publish lists of their IP ranges so you can block then in your server or use an RBL.
[+] [-] pjc50|10 years ago|reply
Domestic systems tend to be in configurations that make it hard to accept inbound TCP connections. You could serve SSL on a random port and open a port using UPNP, and it will work most of the time.
It's a difficult circle to square. The most trustworthy system is one you administer yourself and manually inspect all updates, but in practice the amount of work required makes that almost impossible. If you allow the OEM to do updates they can compromise you. If you don't do updates you end up vulnerable to exploits.
The "send a reference to the message not the message" technique was part of DJB's "internet mail 2000" proposal: https://en.wikipedia.org/wiki/Internet_Mail_2000
[+] [-] chrissnell|10 years ago|reply
What I'd rather see is a company go into partnership with the big providers to certify individual senders at home. The idea is that you'd put up some kind of bond (a few hundred USD?) to help ensure that you won't be sending spam. In exchange for your bond, the company vouches for your IP to Google/Yahoo/Hotmail/etc and you're allowed to send your own email. After some period of use w/o any spam complaints, you get your bond money back.
[+] [-] bhauer|10 years ago|reply
In any event, I found that mainstream ISPs are willing to unblock port 25 if you tell them you are running a personal mail server and have it properly configured to not relay for unauthenticated users.
Aside from that, you'll want one static IP to make your life easy so you don't need to use dynamic DNS.
I think matters such as availability of your server and configuration are surmountable challenges.
But I strongly agree with you about security. Although I really like the idea of this device, the first thing I noticed in the product web page is the use of PHP Roundcube for webmail. I have a fear of running PHP anywhere on my network. The track record [1] is way better than, say, Wordpress, but seeing things like Exec Code, even back in 2008, gives me pause.
[1] http://www.cvedetails.com/vulnerability-list/vendor_id-8905/...
[+] [-] ised|10 years ago|reply
Perhaps it was something like a PUT command to append to a user's "mail" file on the recipient computer?
This seems to suggest email was always envisioned as something to be "received" rather that voluntarily "retrieved".
In retrospect, knowing what happened to email, the later idea (e.g., djb's proposal) makes more sense.
The funny part is that even though the "receive" idea is still the core part of the email process, that is not what email users do in practice.
Users "retrieve" their mail from some third party who receives it for them.
First there was "POP" then there was "webmail".
Back in the Stone Age when email was "invented" computers were too expensive for the users to own.
Each user shared the computer with other users.
Each had an email account, usually administered by the organization that owned the expensive computer.
Today computers are inexpensive and seemingly all users own one but they still do not have control of their email accounts.
Some organization is still receiving all their mail before they do. And keeping a copy of course. :)
Then, in more recent history, the domain name "business" (a monopoly run by an organization that derives its "authority" from nowhere), fueled by the popularity of the "www", became the gatekeeper to email.
When was the last time you sent an email to user@[ipaddr]? Originally if my memory of the old RFC's is correct that was how it worked. No domain name needed.
Today, if there is no purchased, monopoly-blessed "domain name", then according to the people who control users' email there is no "valid" email address. No pay, no play. Even if port 25 is open.
Assuming a user who has paid for access to the "internet" wants control of their own email (seems reasonable), then "email" is still an addtional fee.
[+] [-] LordKano|10 years ago|reply
[+] [-] api|10 years ago|reply
[+] [-] masukomi|10 years ago|reply
[+] [-] radiospiel|10 years ago|reply
Consequently I doubt that a relevant audience for that type of device really exist -- even though I wished own-mailbox would succeed.
[+] [-] tptacek|10 years ago|reply
The underlying approach this system uses --- webmail, but on a special purpose box the user owns --- is actually sound. It seems like a pretty good refinement of Mailpile.
On the other hand, they should tone the rhetoric down. I winced at "100% secure".
[+] [-] jrnvs|10 years ago|reply
From TFA: ➜Can you explain more in details how Private Link Message (PLM) works? Private Link Message (PLM) allows you to send and receive messages from people who don't use GPG.
In order to send a message you can send a secret HTTPS link to your correspondent. It will look like https://test.nospy.co/n3FVgtFwR2cp839nX6dkQGzGjF38bJ5VwiX86u... .
The link is temporary: once clicked by your correspondent it is too late to spy, the link does not work anymore.
You can also, optionaly, setup an expiration date for the link. If your correspondent did not access the message before this date, it is too late to read.
The link is filtered by a question. Depending on the level of surveillance you think you are in, the question can be a simple captcha to avoid bots, a secret question that your correspondent can answer but not the NSA, or a request for a password previously exchanged with your correspondent, or no question at all.
Your correspondent will have a web interface to answer your message privately. You can also activate a permanent HTTPS interface for anyone to send you a message privately at any time.
In practice a simple captcha will allow you to be safe from mass surveillance, since only targeted surveillance can be done by human beings. On top of that any spy will be detected, and have his IP address revealed. On our test, no PLM has ever been spyed even with no question at all.
[+] [-] daenney|10 years ago|reply
> The link is filtered by a question. Depending on the level of surveillance you think you are in, the question can be a simple captcha to avoid bots, a secret question that your correspondent can answer but not the NSA, or a request for a password previously exchanged with your correspondent, or no question at all.
> Your correspondent will have a web interface to answer your message privately. You can also activate a permanent HTTPS interface for anyone to send you a message privately at any time.
Granted, 100% secure is a bold claim, but it's not just an HTTPS link anyone can click on, at least not if you're a tiny bit clever enough to enable additional protection it offers.
[+] [-] Tomte|10 years ago|reply
As I already said last time this product came up: this is not email. As far as encryption is concerned, it's a proprietary messenger, and it deprives not only the user (who opted in), but all of his recipients of virtually every advantage, standard email has got.
[+] [-] _asciiker_|10 years ago|reply
EDIT: I understand SMTPs are resilient but it also depends on the type of error they get back, even then it can't be expected that all servers keep retrying for long periods of time or even handle triple bounces. So you 'could' start losing emails right away, is a better way of saying it.
[+] [-] jakobegger|10 years ago|reply
[+] [-] ryan-c|10 years ago|reply
[+] [-] pjc50|10 years ago|reply
[+] [-] jlgaddis|10 years ago|reply
The "de facto standard" for retrying was (is?) five days, because that's what sendmail defaulted to for years. Nowadays, many senders don't retry that long (my mail systems are set for 48 hours) simply so that a bounce/undeliverable mail is returned to the sender much sooner.
IIRC, there was a certain version of Exchange (I forget which now) that apparently didn't retry and would immediately bounce a message if it was undeliverable on the first attempt, but that was quickly fixed.
[+] [-] lsc|10 years ago|reply
A home mail server, from experience and from the experiences of others, would work okay on receive. You want a static IP (or a static-IP VPN.) at a minimum, and the first thing you need is to make sure you aren't on the dialup-user lists. But that's an outgoing mail issue, not an incoming mail issue.
that's the thing, though, the outgoing mail issue, ultimately, is more difficult than the incoming mail issue.
[+] [-] slg|10 years ago|reply
[+] [-] rythie|10 years ago|reply
Further resilence could be handled by partering with another device at a trusted person's house, to act as a backup MX server.
[+] [-] pppp|10 years ago|reply
[+] [-] Someone1234|10 years ago|reply
Only way around all of this is to pay for a "business" internet connection (with 500% markup for the same speed, single dedicated IP, and a pretty poor SLA).
[+] [-] jlgaddis|10 years ago|reply
[+] [-] uncletaco|10 years ago|reply
[+] [-] pilif|10 years ago|reply
Of course this means that they could read your email again, so we'd be back to square one.
[+] [-] upofadown|10 years ago|reply
[+] [-] hrbrtglm|10 years ago|reply
[+] [-] corv|10 years ago|reply
[+] [-] rogeryu|10 years ago|reply
Land of the free! Start your own ISP! ;-)
[+] [-] lisper|10 years ago|reply
https://github.com/Spark-Innovations/SC4
It's open-source and audited. Based on TweetNaCl. Feedback very much appreciated.
[+] [-] dimino|10 years ago|reply
[+] [-] nadams|10 years ago|reply
> Port 25 is blocked inbound on most residential accounts - preventing you from receiving email
> Many SMTP servers are configured to automatically bounce email from residential IPs - so sending would be a problem
The point of GPG is to make sure that the only person that can read the message is the one you sent it to. Having a HTTPS site doesn't prevent the random person from viewing the link and doesn't verify the user. Now - this might be interesting if the web app that shows the email has as GPG library in Javascript requiring the user to have GPG keys.
I think a better scenario is if keys haven't been exchanged - to send an email with "Alice would like to communicate over secure email - please download and generate a set of keys" with instructions on what to do. But I have no idea how not to make it look spammy.
This is just hilarious:
> Why shouldn't I trust and use any cloud email service with JavaScript client-side encryption?
> Encryption is done in JavaScript, and therefore relies on browser's JavaScript engines, which 80% of the time [1] are proprietary software coming from Google, Microsoft, and Apple, most eminent NSA collaborators.
The author does know that Chrome is open source right (well I guess technically Chromium but I hope it's based on the same code)?
> Why not use a raspberry Pi?
> Mainly because it cannot be trusted enough for this kind of application. [...] The Raspberry pi is provided with non-free software and the hardware needs non-free driver to work.
I've used Debian Linux on it before and didn't need to install third party drivers?
[+] [-] phaer|10 years ago|reply
* Policies of ones ISP are often a problem for something like this, you likely need a "business connection" for something like this.
* Dynamic DNS could be used for receiving, but you won't have much success in sending mails unless you have reverse DNS working and that requires a static IP as far as i know. Most users will only get a static IP for "business connections".
* I'd be really interested how the combine their usage of GPG with multiple client. Is there some sort of key management included? How does it work with Webmail/Roundcube? Is the same key used for desktop and mobile phones?
[+] [-] dlapiduz|10 years ago|reply
[+] [-] Touche|10 years ago|reply
[+] [-] skrowl|10 years ago|reply
[+] [-] inglor|10 years ago|reply
So really, it has both off and on site backup.
[+] [-] jlgaddis|10 years ago|reply
[+] [-] quadrangle|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] h4waii|10 years ago|reply
"rasberry Pi"
"Plug at your home"
"Through a webmail"
"Plug it in mini-usb to your computer"
"Will I get a root access"
Why not have somebody with English as their first language give it a look before making it public?
[+] [-] darkhorn|10 years ago|reply
[+] [-] dfar1|10 years ago|reply
[+] [-] zekevermillion|10 years ago|reply
[+] [-] antrover|10 years ago|reply
[+] [-] junto|10 years ago|reply
> Each Own-Mailbox will generate automatically its SSL key at first setup, and send to us the public part.
> Letsencrypt Certification Authority will be used , it is free and very easy to setup, and it will be handled automatically by your Own-Mailbox. Every Own-Mailbox will automatically ask for certification for its key indepently from us.
Interesting idea.
[+] [-] amelius|10 years ago|reply
[+] [-] padm|10 years ago|reply
It's some sort of "freedombox" [0] come true. It works out of the box, in a plug and play fashion (and it's based on free hardware [1] and free software [2]).
[0] https://en.wikipedia.org/wiki/FreedomBox
[1] https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-...
[2] Debian, https://yunohost.org ,...
[+] [-] Tloewald|10 years ago|reply
The solution for all of us is to make ordinary communication more expensive to break into rather than to go out on a limb with attention-getting extraordinary measures.
I'd also have to say -- no offense intended -- that what I take to be a central European accented voice-over advocating using a new security product to avoid NSA surveillance doesn't fill me with confidence. I'm pretty sure the NSA is at least well-intentioned.
I'd suggest your best pitch accent would be scandinavian or perhaps Australian (not that the Australian government isn't horrible, but it's pretty harmless).
[+] [-] biturd|10 years ago|reply