You are currently viewing all posts tagged with privacy.

privacy, finance

Better Payments with Privacy.com

Privacy.com is an excellent service with a terrible name. They provide merchant-locked virtual debit cards. I’ve been using them for about three years. Around 90% of my online transactions go through them (the other 10%-ish is PayPal).

When one of their card numbers is first used, it becomes locked to that merchant. The card will reject transactions from anyone else. This immediately eliminates the problem of stolen card numbers. If a random ecommerce website leaks my card details, I don’t care, because nobody other than the original merchant can place a charge on the card.

When generating cards, Privacy.com also allows you to set dollar limits, either in total or for a period of time. This eliminates the problem of unreliable subscription services. For example, the card tied to my Amazon Web Services account has a monthly usage limit slightly higher than my average monthly bill. If AWS tries to double my bill one month, the transaction will be rejected.

Cards can also be paused. While I use the periodic dollar limit feature for things like subscription services with regular payments, other cards in my Privacy.com account stay paused when not in use. A paused card rejects all new transactions. Before making a purchase on a website, I login to the Privacy.com website and unpause the associated card. I then make the purchase as usual. Placing an order usually results in the merchant immediately placing an authorization on the card for the purchase amount. Existing authorizations can still be captured on a paused card, so at this point I can switch back to my Privacy.com tab and re-pause the card, preventing the merchant from taking any more money than the agreed upon authorization.

Cards can also be closed. Effectively this is the same as pausing a card, except that it is permanent. This is useful for signing up for free trials that still require a method of payment. When the trial is up, if you choose to not continue using the service, inform the provider and simply close the card.

Privacy.com offers software you can install on your telephone. I’ve never used it. I don’t trust my phone enough for it to touch money in any way. They also offer browser extensions, which I also have never used. Their website works great, and I see no need for locally installed software of any sort.

Over my few years of using Privacy.com, I’ve never had a problem with their service. I’ve never had to contact their customer support, so I have no idea how that works. I’ve had merchants issue refunds to my Privacy.com cards half a dozen or so times, and those have always come through and landed in my bank account without drama (even when the original charge was on a card that at the time of refund was paused or closed.

Last year, Swift Silent Deadly posted an in-depth overview of Privacy.com. This provides a good overview of the service. What he wrote matches my experience, with one glaring exception. He mentions giving Privacy.com access to your bank account. I don’t know if he is referencing some shady Plaid bullshit or if he simply means providing them with routing and account numbers and going through ACH. I did neither. When I signed up, Privacy.com allowed me to add my real bank debit card as a funding source. That is the only way Privacy.com has to push or pull funds from me. If they ever become untrustworthy, I can just cancel my real debit card, and Privacy.com will loose all access to my money.

The debit card that I use for this is tied to the checking account that I previously used only for PayPal. This provides an additional layer of defense, in that there isn’t much money hanging around in that account for someone to steal. I usually keep around $100 in it for incidental purchases, and transfer more in from my real accounts when I plan to make a larger purchase.

Privacy.com has free and paid tiers. I am on the free tier. Apparently it has some limitations in terms of number of cards generated per month and total monthly spend. I have never run into these limitations so I have no idea what they are. They claim that they make enough money on us low-volume free tier users by collecting the transaction fees that merchants pay to process debit cards. I would be very unhappy to return to participating in the electronic commerce market without a service like this, so they would probably have a pretty easy time convincing me to move to a paid plan if they ever decided to eliminate the free tier.

I’ve heard some banks offer virtual card numbers somewhat similar to Privacy.com, but perhaps without the merchant-locking and spend limits. While I refer to my “bank” accounts, my accounts are actually with credit unions. Credit unions tend not to be at the forefront of technology, so I need a third-party to provide this functionality.

Privacy.com says that they offer merchant masking to their paying customers. This means that transactions show up in your bank account as “Privacy.com” instead of including the name of the merchant. I suspect this may be where their business name comes from. I suppose that is great if you have a joint bank account and want to hide your Porn Hub subscription from your spouse. But it is not a problem I have, so I maintain that their name is dumb and has nothing to do with their excellent service. If anything they reduce my privacy, since they are now an additional party involved in all of my online purchases. But I’m good with that trade-off.

micro, privacy

Identifying individuals by using a laser to record the vibrations of their heartbeat is a neat idea.

The Pentagon’s new Jetson laser sounds like a simple concept:

A new device, developed for the Pentagon after US Special Forces requested it, can identify people without seeing their face: instead it detects their unique cardiac signature with an infrared laser. While it works at 200 meters (219 yards), longer distances could be possible with a better laser. “I don’t want to say you could do it from space,” says Steward Remaly, of the Pentagon’s Combatting Terrorism Technical Support Office, “but longer ranges should be possible.”

Contact infrared sensors are often used to automatically record a patient’s pulse. They work by detecting the changes in reflection of infrared light caused by blood flow. By contrast, the new device, called Jetson, uses a technique known as laser vibrometry to detect the surface movement caused by the heartbeat. This works though typical clothing like a shirt and a jacket (though not thicker clothing such as a winter coat).

I wonder if they aim center mass, or if they can get a reading off the carotid. If it’s the former, it seems likely to be defeated by wearing plates, which is probably good life advice if the Pentagon is interested in you anyways.

The article also mentions that “[o]ne glaring limitation is the need for a database of cardiac signatures”, but I suspect they can just acquire that data from Apple, Strava, Fitbit, etc.

via Infowarrior

micro, privacy, blogroll

Geoff Manaugh discusses the deception and misdirection of robot vision.

Starting with the recent Tesla crash caused by the car’s inability to discern the tractor against the bright sky, Geoff discusses how the spread of robots may force us to rebuild our environment – either to support their perceptual systems or hinder them. It’s an interesting idea to ponder, particularly within the context of the rise of drones. Readers of Daniel Suarez can sleep easier at night knowing that razorbacks can probably be defeated with a few mirrors and rubber.

One possible line of defense—among many, of course—would be to redesign your city, even down to the interior of your own home, such that machine vision is constantly confused there. You thus rebuild the world using light-absorbing fabrics and reflective ornament, installing projections and mirrors, screens and smoke. Or “stealth objects” and radar-baffling architectural geometries. A military robot wheeling its way into your home thus simply gets lost there, stuck in a labyrinth of perceptual convolution and reflection-implied rooms that don’t exist.

crypto, privacy

Cryptographic Identity

Despite its shortcomings, I think PGP is still one of the better ways to verify a person’s identity. Because of this – and because I use my PGP key daily1 – I make an effort to properly secure my private key. Verifying a PGP key is a fairly straightforward process for fellow PGP users, and my hope is that anyone who does verify my key can maintain a high confidence in its signature.

However, I also use other cryptographic channels to communicate – XMPP/OTR and Signal chief among them. I consider these keys more transient than PGP. The OTR keys on my computer are backed up because it takes no effort to do so, but I have no qualms about creating new ones if I feel like it. I don’t bother to port the same keys to other devices, like my phone. My Signal key is guaranteed to change anytime I rebuild or replace my phone. Given the nature of these keys and how I handle them, I don’t expect others to put the same amount of effort into verifying their fingerprints.

The solution to this is to maintain a simple text file, signed via PGP, containing the fingerprints of my other keys. With a copy of the file and a trusted copy of my public PGP key, anyone can verify my identity on other networks or communication channels. If a key is replaced, I simply add the new fingerprint to the file, sign it and distribute. Contacts download the file, check its signature, and thus easily trust the new fingerprint without additional rigmarole.

The first examples of this that I saw were from Yan and Tom Lowenthal. I thought it seemed like a great idea and began to maintain a file with a list of examples whenever I stumbled across then, with a note that I should do that someday2.

Today I decided to stop procrastinating on this and create my own identity file. It is located at pig-monkey.com/id.txt. The file, along with the rest of this website, is in git so that changes to it may be tracked over time.

Inspired by some of the examples I had collected, I added a couple pieces of related information to the file. The section on PGP key signing should provide others some context for what it means when they see my signature on a different key. Even if no one cares, I found it useful to enunciate the policy simply to clear up my own thinking about what the different certification levels should mean. Finally, the section on key management gives others a rough idea about how I manage my key, which should help them to maintain their confidence in it. If I verify that someone’s identity and fingerprint match their key, I will have high confidence in its signature initially. But if I know that the person keeps their secret key on their daily driver machine without any additional effort to protect it, my confidence in it will degrade over time. Less so if I know that they take great care and handling in their key’s protection.

A file like this should also provide a good mechanism for creating a transition and revocation statement for my PGP key, should the need arise. One hopes that it does not.

Notes

  1. ↵ Realistically, I use PGP multiple times per hour when I'm on my computer.
  2. ↵ Since I began my list, Keybase has become a thing. It addresses a similar problem, although seems to promote using services like Twitter as the root of trust. Assuming that you want to stubbornly stick with a PGP key as the root of trust, I don't see the advantage of using Keybase for this problem, except that it offers a centralized lookup repository.
micro, privacy, finance

Lately I've had trouble finding prepaid debit cards in denominations greater than $50.

It’s 2016, and stuffing cash in an envelope and mailing it to a small island nation is sometimes still the best way to move money with some degree of privacy.

This is not the cyberpunk dystopia I was promised.

linux, privacy

Isolating Chrome Apps with Firejail

Despite its terse man page, Chromium provides a large number of command-line options. One of these is app-id, which tells Chromium to directly launch a specific Chrome App. Combined with the isolation provided by Firejail, this makes using Chrome Apps a much more enjoyable experience.

For instance, I use the Signal Desktop app. When I received the beta invite, I created a new directory to act as the home directory for the sandbox that would run the app.

$ mkdir -p ~/.chromium-apps/signal

I then launched a sandboxed browser using that directory and installed the app.

$ firejail --private=~/.chromium-apps/signal /usr/bin/chromium

After the app was installed, I added an alias to my zsh configuration to launch the app directly.

alias signal="firejail --private=~/.chromium-apps/signal /usr/bin/chromium --app-id=bikioccmkafdpakkkcpdbppfkghcmihk"

To launch the application I can now simply run signal, just as if it was a normal desktop application. I don’t have to worry about it accessing private information, or even care that it is actually running on Chromium underneath. I use this method daily for a number of different Chrome Apps, all in different isolated directories in ~/.chromium-apps. As someone who is not a normal Chromium user, it makes the prospect of running a Chrome App much more attractive.

micro, privacy, finance

I stopped worrying and embraced the security freeze.

A credit security freeze denies access to your credit file. I first learned about it last summer from Brian Krebs, but didn’t implement it until a couple months later. It took me about 45 minutes and $20 to activate the freeze with the five major credit bureaus. This goes a long way to reducing the threat of identify theft, with very little energy expenditure required. A proactive defense is superior to reactive monitoring services. If you need your credit pulled monthly or more frequently, constantly freezing and unfreezing your file would probably be an annoying inconvenience. For the rest of us, I’m not sure if there is any good reason not to enable the freeze.

linux, privacy

Firewarden

I’ve previously mentioned the Firejail sandbox program. It’s an incredibly useful tool. I use it to jail pretty much all the things. Over the past six months, I’ve found that one of my primary use cases for Firejail is to create private, temporary sandboxes which can be destroyed upon closure. I wrote Firewarden, a simple wrapper script around Firejail, to reduce the keystrokes needed for this type of use.

Disposable Browsers

Prepend any program with firewarden and it will launch the program inside a private Firejail sandbox. I use Firewarden to launch disposable Chromium instances dozens of times per day. When the program passed to Firewarden is chromium or google-chrome, Firewarden will add the appropriate options to the browser to prevent the first run greeting, disable the default browser check, and prevent the WebRTC IP leak. The following two commands are equivalent:

$ firejail --private chromium --no-first-run --no-default-browser-check --enforce-webrtc-ip-permission-check
$ firewarden chromium

Firewarden also provides a few options to request a more restricted Firejail sandbox. For instance, you may want to open a URL in Chromium, but also use an isolated network namespace and create a new /dev directory (which has the effect of disabling access to webcams, speakers and microphones). The following two commands are equivalent:

$ firejail --private --net=enp0s25 --netfilter --private-dev chromium --no-first-run --no-default-browser-check --enforce-webrtc-ip-permission-check https://example.org
$ firewarden -d -i chromium https://example.org

In this example, Firewarden used NetworkManager to discover that enp0s25 was the first connected device, so it used that for the network namespace.

Local Files

Firewarden isn’t just useful for browsers. It can be used with any program, but my other major use case is safely viewing local files. File types like PDF and JPG can include malicious code and are a primary vector for malware. I use zathura as my PDF reader, which is a simple and lightweight viewer that doesn’t include anywhere near the number of potential vulnerabilities as something like Adobe Acrobat, but I still think it prudent to take extra precautions when viewing PDF files downloaded from the internet.

If Firewarden thinks the final argument is a local file, it will create a new directory in /tmp, copy the file into it, and launch the program in a sandbox using the new temporary directory as the user home directory1. Firewarden will also default to creating a new /dev directory when viewing local files, as well as disabling network access (thus preventing a malicious file from phoning home). When the program has closed, Firewarden removes the temporary directory and its contents

$ firewarden zathura notatrap.pdf

The above command is the equivalent of:

$ export now=`date --iso-8601=s`
$ mkdir -p /tmp/$USER/firewarden/$now
$ cp notatrap.pdf /tmp/$USER/firewarden/$now/
$ firejail --net=none --private-dev --private=/tmp/$USER/firewarden/$now zathura notatrap.pdf
$ rm -r /tmp/$USER/firewarden/$now

I use this functionality numerous times throughout the day. I also include Firewarden in my mailcap, which goes a long way to reducing the dangers of email attachments.

Firewarden doesn’t add any new functionality to Firejail, but it does make it easier to take advantage of some of the great features that Firejail provides. Check it out if you’re interested in reducing the keystrokes required to Jail All The Things™.

Notes

  1. ↵ This is similar to using Firejail's old --private-home option, which was removed in 0.9.38. However, that option was limited to files in the user's home directory. It couldn't be easily used with a file from a USB drive mounted at /media/usb, for instance.