Shallow Thoughts : tags : privacy

Fetching Browser Cookies Programmatically

In my eternal quest for a decent RSS feed for top World/National news, I decided to try subscribing to the New York Times online. But when I went to try to add them to my RSS reader, I discovered it wasn't that easy: their login page sometimes gives a captcha, so you can't just set a username and password in the RSS reader.

A common technique for sites like this is to log in with a browser, then copy the browser's cookies into your news reading program. At least, I thought it was a common technique -- but when I tried a web search, examples were surprisingly hard to find.

None of the techniques to examine or save browser cookies were all that simple, so I ended up writing a browser_cookies.py Python script to extract cookies from chromium and firefox browsers.

Read more ...

Tags: web, programming, python, cookies, privacy
[ 11:19 Mar 30, 2021    More programming | permalink to this entry | ]

U is for Unreliable UI (or: Why Firefox's "Do this automatically this from now on" checkbox is so flaky, and how to work around it)

It's been a frustration with Firefox for years. You click on a link and get the "What should Firefox do with this file?" dialog, even though it's a file type you view all the time -- PDF, say, or JPEG. You click "View in browser" or "Save file" or whatever ... then you check the "Do this automatically for files like this from now on" checkbox, thinking, I'm sure I checked this last time.

Then a few minutes later, you go to a file of the exact same time, and you get the dialog again. That damn checkbox is like the button on street crossings or elevators: a no-op to make you think you're doing something.

I never tried to get to the bottom of why this happens with some PDFs and not others, some JPGs but not others. But Los Alamos puts their government meetings on a site called Legistar. Legistar does everything as PDF -- and those PDFs all trigger this Firefox bug, prompting for a download rather than displaying in Firefox's PDF viewer.

Read more ...

Tags: firefox, web, privacy
[ 16:38 Aug 08, 2020    More tech/web | permalink to this entry | ]

P is for Privacy

The LWV Los Alamos is running a Privacy Study, which I'm co-chairing. As preparation for our second meeting, I gave a Toastmasters talk entitled "Browser Privacy: Cookies and Tracking and Scripts, Oh My!" A link to the talk video, a transcript, and lots of extra details are available on my newly created Privacy page.

Tags: tech, privacy, speaking
[ 08:58 Jun 26, 2020    More tech | permalink to this entry | ]

Privacy Policy

I got an envelope from my bank in the mail. The envelope was open and looked like the flap had never been sealed.

Inside was a copy of their privacy policy. Nothing else.

The policy didn't say whether their privacy policy included sealing the envelope when they send me things.

Tags: privacy, security, humor
[ 13:22 Aug 05, 2014    More humor | permalink to this entry | ]

Email is not private

Microsoft is in trouble this week -- someone discovered Microsoft read a user's Hotmail email as part of an internal leak investigation (more info here: Microsoft frisked blogger's Hotmail inbox, IM chat to hunt Windows 8 leaker, court told). And that led The Verge to publish the alarming news that it's not just Microsoft -- any company that handles your mail can also look at the contents: "Free email also means someone else is hosting it; they own the servers, and there's no legal or technical safeguard to keep them from looking at what's inside."

Well, yeah. That's true of any email system -- not just free webmail like Hotmail or Gmail. I was lucky enough to learn that lesson early.

I was a high school student in the midst of college application angst. The physics department at the local university had generously given me an account on their Unix PDP-11 since I'd taken a few physics classes there.

I had just sent off some sort of long, angst-y email message to a friend at another local college, laying my soul bare, worrying about my college applications and life choices and who I was going to be for the rest of my life. You know, all that important earth-shattering stuff you worry about when you're that age, when you're sure that any wrong choice will ruin the whole rest of your life forever.

And then, fiddling around on the Unix system after sending my angsty mail, I had some sort of technical question, something I couldn't figure out from the man pages, and I sent off a quick question to the same college friend.

A couple of minutes later, I had new mail. From root. (For non-Unix users, root is the account of the system administrator: the person in charge of running the computer.) The mail read:

Just ask root. He knows all!

followed by a clear, concise answer to my technical question.

Great! ... except I hadn't asked root. I had asked my friend at a college across town.

When I got the email from root, it shook me up. His response to the short technical question was just what I needed ... but if he'd read my question, did it mean he'd also read the long soul-baring message I'd sent just minutes earlier? Was he the sort of snoop who spent his time reading all the mail passing through the system? I wouldn't have thought so, but ...

I didn't ask; I wasn't sure I wanted to know. Lesson learned. Email isn't private. Root (or maybe anyone else with enough knowledge) can read your email.

Maybe five years later, I was a systems administrator on a Sun network, and I found out what must have happened. Turns out, when you're a sysadmin, sometimes you see things like that without intending to. Something goes wrong with the email system, and you're trying to fix it, and there's a spool directory full of files with randomized names, and you're checking on which ones are old and which are recent, and what has and hasn't gotten sent ... and some of those files have content that includes the bodies of email messages. And sometimes you see part of what's in them. You're not trying to snoop. You don't sit there and read the full content of what your users are emailing. (For one thing, you don't have time, since typically this happens when you're madly trying to fix a critical email problem.) But sometimes you do see snippets, even if you're not trying to. I suspect that's probably what happened when "root" replied to my message.

And, of course, a snoopy and unethical system administrator who really wanted to invade his users' privacy could easily read everything passing through the system. I doubt that happened on the college system where I had an account, and I certainly didn't do it when I was a sysadmin. But it could happen.

The lesson is that email, if you don't encrypt it, isn't private. Think of email as being like a postcard. You don't expect Post Office employees to read what's written on the postcard -- generally they have better things to do -- but there are dozens of people who handle your postcard as it gets delivered who could read it if they wanted to.

As the Verge article says, "Peeking into your clients' inbox is bad form, but it's perfectly legal."

Of course, none of this excuses Microsoft's deliberately reading Hotmail mailboxes. It is bad form, and amid the outcry Microsoft has changed its Hotmail snooping policies somewhat, saying they'll only snoop deliberately in certain cases).

But the lesson for users is: if you're writing anything private, anything you don't want other people to read ... don't put it on a postcard. Or in unencrypted email.

Tags: email, privacy, tech
[ 14:59 Mar 27, 2014    More tech/email | permalink to this entry | ]

Fireballs -- an easier variant on the paper brick

I wrote, some time ago, about making burnable paper bricks as an alternative to shredding sensitive paper material that also helps keep you warm in winter.

We recently got pulled in to help with disposing of quite a large cache of sensitive paper, and have discovered a much faster method than the "let sit and stir occasionally" technique.

The trick is to use hot water, ideally with a little soap added. Hot soapy water breaks down the paper quite quickly; the soap helps it break down, and may also help the paper stick together better as it dries.

Stir the mess around a bit, and in as little as a few hours you can fish up handfuls of paper goosh them into nice compact tennis balls. (Though if you can let it sit overnight, so much the better.)

Try to squeeze out as much water as you can, and keep the balls reasonably small, so they'll dry quickly. Ours have been ranging from tennis ball sized to softball sized.

Then put the fireballs out in the sun to dry. We have them on a tarp in the backyard. If anyone visits, tell them it's an art project.

They feel fairly dry on the outside after a day or two, but of course the insides are still wet -- I'd let them sit for at least several weeks before throwing them into the fireplace. Don't want to smoke up the house! Fortunately, with temperatures in the nineties, I don't think we'll be needing the fireplace terribly soon.

Do check first whether your bucket's in reasonable shape. The first bucket we tried turned out to be brittle, and the bottom exploded a bit after putting the paper in. Oops! Brittle Bottom Syndrome seems to be a common fate of buckets that sit out in the backyard for too long.

But at least this photo shows the state of the paper after a short time sitting in the soapy water. I don't think anybody's going to be reading names or credit card numbers off any of these documents, whether or not they're gooshed into a ball.

We're accumulating so many fireballs that I'm hoping to try burning a pyramid of them some time this winter.

Tags: recycling, privacy
[ 15:55 Oct 01, 2012    More misc | permalink to this entry | ]

Why shred, when you can make paper bricks?

What do you do about all that mail -- junk and otherwise -- with incriminating information on it? You know, the stuff with your name and bank account numbers and such that you don't want an identity thief to get? If you toss them in the recycling (or, worse, the trash), who knows what might happen to them between here and the recycling plant?

Some people buy a shredder -- an electric lump of a thing that sits in a corner and turns paper into streamers. I guess it sounds kinda fun, but it costs money, uses electricity and takes up space. Or you can take all the assorted bits of paper and burn them in the fireplace or barbecue, but that's kind of a hassle and it makes a lot of ash and smoke.

A few years ago, Dave came up with what we think is a better idea: we make the paper into condensed paper fire-bricks, which we then burn the fireplace. They burn much cleaner and more slowly than those bits of paper, and they're fun to make. Here's how.

First, you collect a lot of paper -- we keep a separate wastebasket where we crumple all the papers (no need to shred them).

When you have enough to start a batch, put the papers in a bucket or other container, and fill with enough water that the paper is covered.

Let that sit for a while -- a week or two -- stirring occasionally (maybe twice a day). Ideally, you want the paper to break down to a soup in which you can't read any of the incriminating text. But if you get impatient, you can move on to the next step little early as long as all everything has gotten soft and the paper is starting to break up.

Once everything's soft and soupy, you want a mold of whatever shape you want your eventual brick to be. Cardboard ice cream containers (pictured here) work nicely, or you can use a bowl, a small bucket, practically anything.

Transfer the wet mush into your mold, squeezing out as much excess water as you can. The drier you can get it, the less time it will take to cure. Pack it into your mold as tightly as you can (understanding that if you're using a cardboard ice cream container, it can't take much packing of wet stuff).

Put the mold in a sunny place in the hard to dry, if possible. You can speed the process along by using a mold that lets excess water drain, or by compressing the mush every so often (once or twice a day) and letting any water run out. Early on, we put weights on top to keep the mush compressed, but it doesn't seem to make that much difference.

When it seems quite dry, remove it from the mold. (This mold is an old microwave popcorn making bowl that cracked, so it's no longer good for making popcorn.)

Early on, we thought it might be interesting to pack in some other flammable material, like bits of wood and nutshells left over from feeding squirrels. That gives you a lumpy breccia (the lower brick in the picture) that doesn't burn very consistently, because it's full of holes. Not a good idea, as it turned out.

The upper brick in the photo is what you get if you let your soup dissolve for a long time and don't add any lumpy stuff to it: a nice smooth brick of pressed paperboard. It's okay to add a bit of small soft stuff like dryer lint. But skip the nutshells -- those can go in the compost bin or yard waste container.

Your final brick, removed from the mold, should be a nice homogeneous piece of paperboard. It's still fairly light and not very dense ... but it burns smoothly and cleanly, and doesn't send sparks up the chimmney like those original bits of paper would have.

Save on heating bills? Well, if you make paper bricks all summer, by winter time you'll probably have saved up enough to burn for ... maybe an hour or two. No, this isn't going to heat your home. Still, it's an amusing, inexpensive and electricity-free way of disposing of that pesky printed privacy-pilfering paper that plagues us all.

Tags: recycling, privacy
[ 10:43 Sep 13, 2011    More misc | permalink to this entry | ]

PII 2011: Privacy, Identity and Innovation conference

I'm just now finding time to write up some of my notes from PII: Privacy, Identity and Innovation last week. PII was a fabulous conference, fascinating and well run. It was amazing to be in a room with so many people who actually care about these issues.

There were two days of speakers and panels, most of them in the same room, which surprised me: usually conferences have multiple tracks to give you lots of choices. But I ended up being glad for the single track. Almost all of the speakers and panels were interesting, including some I might not have chosen on my own. I had my laptop along with some projects I figured I'd work on during the boring sessions -- but that never happened. I didn't even get time during lunch or breaks -- too many fascinating people to talk to in the hallways.

Then Saturday was "Privacy Camp", a less formal "unconference" full of round-table discussions about some of the issues raised during the regular conference. Conversations were lively and informative.

Usually after a conference I have a couple of suggestions for improvement. For PII I really can't come up with anything. The website was very informative (they even had detailed parking information), everything ran pretty close to on time, rooms were easy to find, they had an A/V crew recording everything, and wow, that Thursday lunch. Plus: Best. Badgeholders. Ever. Great job, PII organizers!

And I couldn't help but notice the gender balance: a third of the speakers were women, and by my rough count-of-nearby-tables, women were close to 40% of the attendees. At a tech conference! That's about double most conferences. Most of the women I talked to were entrepreneurs, many with a history of successful startups already, plus some researchers and a few developers.

The opening talk was worth getting up early for: Julia Angwin, the journalist who wrote the Wall Street Journal's excellent "What they know" articles, discussing the research that led to to the series and what they've learned from it.

Later, once the panel discussions got started, the biggest takeaway from the conference was a question mentioned early on: "Were users surprised? When were they surprised?" Sometimes companies say they care about privacy, but haven't thought much about user expectations. Asking yourself this question is a great test of how well you're really protecting user privacy.

Privacy statements don't work

One of the panels I wouldn't have chosen that was unexpectedly interesting discussed web site privacy statements. First, M. Ryan Calo of the Stanford privacy center presented a study on user behavior with regard to privacy statements. They tried several different types, on websites of very different designs, to see what worked best for users. The upshot? "We couldn't test how well various privacy statements worked, because no users clicked on them. Zero."

Then Aleecia McDonald of Mozilla presented a study where they tried structuring privacy statements in different ways to make the information clearer to users. How can you improve on the "natural-language" policy you see on most websites, consisting of several pages of dense obfuscated text? They tried hierarchies where they showed the basics and let users click through to the details; interactive pages where you could expand and contract sections or mouse over a category to see more; colored tables, cute icons, the works. They found that most of the seemingly easier formats were actually worse than the long natural-language expositions no one reads.

If you make the page interactive, users won't expand the sections and won't find the important mouseovers. If you make sub-pages, users won't click through. If you use icons, users won't know what they mean. But too often, they'll end up thinking they understand, making assumptions about the details that don't match what's really in the policy. So most simplified, "user-friendly" policies are actually worse than a dense wall of text.

The only style that tested slightly better than natural-language policies was the "Nutrition label" style, where they presented several aspects of privacy with ratings for how good or bad the site was.

I felt sorry for the two panelists after Ryan and Aleecia, who were there to show off their cool hierarchical privacy statement page designs. They'd obviously put a lot of work into trying to make their policies clearer ... but we'd just been convincingly shown how ineffective such policies really are.

How to be stupid much faster

One panel discussed big data collection, and some of the ways data can be misused. Someone (Beth Givens?) related a story of a family arrested for marijuana growing after their power company's algorithms flagged them as suspicious for their heavy late-night use of power. Turns out they just had two teenagers who liked to stay up late playing video games. Terence Craig, in my favorite quote from the conference, quipped: "It used to be that it took weeks to accumulate that data. Now you can be stupid much faster."

I enjoyed a workshop given by Brian Kennish of Disconnect and Calvin Pappas of SelectOut about their projects. Disconnect arose from a chrome browser extension, Facebook Disconnect, to block Facebook tracking from widgets on third-party sites. SelectOut also arose from a chrome extension, making it easy for users to opt out of all the major advertising networks at once. The workshop turned into a lively discussion of opt-out versus do-not-track solutions, and what future directions might be.

In another workshop, Martin Ortlieb described a Google study comparing attitudes toward privacy of people in several countries. Someone in the audience asked a question about data being collected and held by government agencies versus private companies. Martin commented that attitudes in the study tended toward "I'd rather companies have my data, because then the government might regulate how it's used. If the government has it, no company's going to regulate it."

Assorted notes

Someone mentioned that Mozilla didn't seem to be taking "Do not track" very seriously, hiding it in the Advanced preferences tab, not under Privacy where you'd expect it. Why? Later we heard that Mozilla is listening to those concerns, and Firefox 5 will move Do Not Track to the Privacy tab.

Esther Dyson: "Personal data can be traded; reputation can't. Reputation is not a currency." She was responding to someone who described a business model involving trading reputation points.

M. Ryan Calo: The government doesn't need a warrant to access your webmail if it's older than 6 months, something most webmail users don't realize.

Finally, Raman Khanna observed: kids get tattoos, then when they're older they pay a lot more for laser removal services. There will be data services like that. "You were stupid when you were in college, and you put all this info online. We'll clean it up for you."

A good insight, and it reminded me of the old threat they used to give us in school (do they still say this to kids?) "This is going on your permanent record." Nobody was ever sure what this permanent record was or why anyone would want to look at it. I wonder if mine still exists somewhere?

Tags: conferences, pii2011, privacy
[ 11:32 May 27, 2011    More conferences | permalink to this entry | ]

In Praise of Logical AND. In Censure of Invasive Cookies.

The tech press is in a buzz about the new search company, Cuil (pronounced "cool"). Most people don't like it much, but are using it as an excuse to rhapsodize about Google and why they took such a commanding lead in the search market, PageRank and huge data centers and all those other good things Google has.

Not to run down PageRank or other Google inventions -- Google does an excellent job at search these days (sometimes spam-SEO sites get ahead of them, but so far they've always caught up) -- but that's not how I remember it. Google's victory over other search engines was a lot simpler and more basic than that. What did they bring?

Logical AND.

Most of you have probably forgotten it since we take Google so for granted now, but back in the bad old days when search engines were just getting started, they all did it the wrong way. If you searched for red fish, pretty much all the early search engines would give you all the pages that had either red or fish anywhere in them. The more words you added, the less likely you were to find anything that was remotely related to what you wanted.

Google was the first search engine that realized the simple fact (obvious to all of us who were out there actually doing searches) that what people want when they search for multiple words is only the pages that have all the words -- the pages that have both red and fish. It was the search engine where it actually made sense to search for more than one word, the first where you could realistically narrow down your search to something fairly specific.

Even today, most site searches don't do this right. Try searching for several keywords on your local college's web site, or on a retail site that doesn't license Google (or Yahoo or other major search engine) technology.

Logical and. The killer boolean for search engines.

(I should mention that Dave, when he heard this, shook his head. "No. Google took over because it was the first engine that just gave you simple text that you could read, without spinning blinking images and tons of other crap cluttering up the page." He has a point -- that was certainly another big improvement Google brought, which hardly anybody else seems to have realized even now. Commercial sites get more and more cluttered, and nobody notices that Google, the industry leader, eschews all that crap and sticks with simplicity. I don't agree that's why they won, but it would be an excellent reason to stick with Google even if their search results weren't the best.)

So what about Cuil? I finally got around to trying it this morning, starting with a little "vanity google" for my name. The results were fairly reasonable, though oddly slanted toward TAC, a local astronomy group in which I was fairly active around ten years ago (three hits out of the first ten are TAC!)

Dave then started typing colors into Cuil to see what he would get, and found some disturbing results. He has Firefox' cookie preference set to "Ask me before setting a cookie" -- and it looks like Cuil loads pages in the background, setting cookies galore for sites you haven't ever seen or even asked to see. For every search term he thought of, Cuil popped up a cookie request dialog while he was still typing.

Searching for blu wanted to set a cookie for bluefish.something.
Searching for gre wanted to set a cookie for www.gre.ac.uk.
Searching for yel wanted to set a cookie for www.myyellow.com.
Searching for pra wanted to set a cookie for www.pvamu.edu.

Pretty creepy, especially when combined with Cuil's propensity (noted by every review I've seen so far, and it's true here too) for including porn and spam sites. We only noticed this because he happened to have the "Ask me" pref set. Most people wouldn't even know. Use Cuil and you may end up with a lot of cookies set from sites you've never even seen, sites you wouldn't want to be associated with. Better hope no investigators come crawling through your browser profile any time soon.

Tags: tech, search, privacy
[ 11:10 Aug 05, 2008    More tech | permalink to this entry | ]