Privacy

[jducoeur]

Note to self: time to start figuring out my privacy policy vis a vis the government.

For the most part, privacy is going to be pretty clearly delineated in CommYou, same as in LJ: you say who can read your conversations, and I do my best to enforce those restrictions. But in the post-Patriot Act world, CommYou's relationship with the US government is potentially complicated, especially if I develop any real amount of international membership. Or, to put it more concretely: I need to figure out how I respond if the FBI shows up and demands access to somebody's private conversations.

With any luck, things will begin to get a little more rational after the election -- in particular, I have some hope that a Democratic president might at least put real teeth back into FISA oversight, so I can demand a clear court order and make that demand stick. But I probably have to assume that things have fundamentally changed enough that, even with the Republicans out of office, some of the climate of fear (and consequent governmental invasions of privacy) will continue.

Gah: really not stuff I want to be thinking about. And I probably have at least six months after launch before CommYou matters enough for the government to even notice its existence. But I need to be pondering this now, before it becomes A Problem, because the panic after getting a call from the FBI is *not* the time to be designing well-thought-out policy...

Comments

[zachkessin.livejournal.com]

Personally I would have something in there about "I am not going to go to jail to protect your privacy" you may disagree but it is something I would stick by. You should probably talk to some lawyers about this of course as well.

[umbran.livejournal.com]

Ouch, yes, that's a difficulty. We have the luck of having a major university's lawyers (and, by extension, much of higher education) backing us up. You're on your lonesome, and that's a bit scary.

[talvinamarich.livejournal.com]

Our Privacy Policy

In the world we wish to create, in the world we wish we lived in, everyone would enjoy a right to privacy.

This service exists in and is governed by the laws of this world: the laws of nation-states, the laws of science, the laws of social interaction, the laws of common-sense, the laws that we like and the laws that we hate.

Both you and this service are at the heartless mercy of those laws and those who write and interpret them.

If you post something here, someone will be able to read it. We cannot guarantee that that person will have your best interests at heart. They may work for our government, for another government, for a tabloid, or it may be some bored kid with a computer that is worth more than he has earned up to this point in his short life. It might even be a "friend" who isn't, really.

If you threaten or attempt to hurt someone, you waive all pretense to a right to privacy in our eyes. If you trade in or conduct business that some jurisdiction that is touched by the Internet considers unlawful or within their power to regulate, it is possible, even probable, that they will attempt to compel us to cooperate with them. This may be done according to what you or I consider to be our inalienable rights--or not.

We did not create this service with the intent of depriving you of privacy. Our intentions are totally opposite: we wish to give you the level of privacy you wish to enjoy.

But we're not going to lie to you, so please don't come crying to us when we are pushed aside and rendered irrelevant in matters of privacy. We can't help you: we're in the same boat.

Enjoy your stay with us!

[baron-steffan.livejournal.com]

I like that a lot. Speaking as a Clueless Mere User [tm], it's straightforward, honest, and something I can accept given the realities of the current zeitgeist we operate in.

[talvinamarich.livejournal.com]

Thank you.

I considered beginning with ,"I thought we would start this Privacy Policy 'by taking some time out of our daily lives to sit down and have a little chat.'"

But that would have been a bit much. :P

[zachkessin.livejournal.com]

Personally I assume that anything that is published without a friendslock on LJ can be read by anyone who wants to*, anything with a friends lock I assume will stand up to moderate scrutiny by people I don't want to read it. What do I mean by that, well using a friends lock to plan a surprise party will probably work, a bank heist not as much. I assume if someone shows up at your door with a court order your response is and should be "Ok here is what you asked for".

[jducoeur]

Not a bad proposed policy -- I like the basic honesty in it. I'd probably word parts of it a bit differently (and I think I'm going to need to consult a lawyer on this point before the service get at all large), but it's a fine starting point. Thanks!

[talvinamarich.livejournal.com]

Make no mistake: my tongue was in my cheek the whole time.

Bit my tongue, though. Ow.

[dreda.livejournal.com]

What's the current state of provider responsibilities? I'm pretty sure that ISPs are no longer being held accountable, but I'm not sure about people like, say, Google for gmail or Yahoo for Hotmail. I would tend to think that you'd fall closer to them from a legal standpoint.

Too bad you inherently can't take the librarian tack, and not ever have any information on hand to surrender...

[jducoeur]

I'm pretty sure that ISPs are no longer being held accountable, but I'm not sure about people like, say, Google for gmail or Yahoo for Hotmail. I would tend to think that you'd fall closer to them from a legal standpoint.

Well, keep in mind that accountability isn't really the issue here. I suspect that CommYou can make a reasonable case for common carriage if I'm careful about it, so I'm probably won't be held *responsible* for what users say. (Although that's still a fraught and uncertain subject.)

The real issue is government snooping. They have been installing backdoors in communication systems where they can -- the legality of that is a bit dubious, but I suspect that they've been exerting a lot of pressure when possible.

More importantly, there's a fairly big question of how free the FBI is to simply demand that communication records be handed over to them, and arrest anyone who doesn't comply. The administration has certainly been taking a hard line on this; again, the legality is sometimes tenuous, but they have enough justification in the Patriot Act to make a lot stick. I *despise* that on principle -- I'm willing to hand over records when faced with a court order, but anything less than that bugs the hell out of me...

[metahacker.livejournal.com]

...or, after they steal seize your computers and retroactively tell you about it.

My thoughts on this include making the chain of weak links visible. "All administrators to this system can see your posts, but promise by contract not to look. The hosting site can see your stuff; see their policy [here]. The government can order any of us to disclose; details [here]. Finally, assuming the site might one day be compromised, [here]'s what we do about it (encryption, backups, etc.)."

Unfortunately I do not anticipate the Patriot and attending acts to disappear any time soon, not unless we re-elect most of Congress. It's not like the act passed by a small, partisan margin.

[jducoeur]

Unfortunately I do not anticipate the Patriot and attending acts to disappear any time soon, not unless we re-elect most of Congress. It's not like the act passed by a small, partisan margin.

True, although I think there's a fair amount of buyer's remorse there -- a lot was done in the heat of the moment that people have regretted since. So there is some hope of gradually weakening the more onerous and stupid bits of the act, although I don't hold out much hope of returning to the status quo ante any time soon...

[metahacker.livejournal.com]

buyer's remorse

Heh. Interesting way to phrase it. :)

[goldsquare.livejournal.com]

You would have no choice. Just admit to what you can control, and admit to what you can't. (Besides, unencrypted bits are powned by the US already, if the news stories are true.)

[jducoeur]

(Besides, unencrypted bits are powned by the US already, if the news stories are true.)

True. Indeed, this relates to one of the stories I'm pondering: whether to provide at least an encrypted wire channel for end users. I don't want to encourage that in most cases -- for most people, for most purposes, it's expensive overkill -- but there are some legitimate and common use cases I can see for it. (In particular, when using the service through suspect wifi channels such as at a Starbucks.) We'll see on that one.

But on the main point: yes, you're undoubtedly correct. But it does stick in my craw, and I'd like to understand the degree of "no choice" I actually have. The telecomms snooping affair illustrates what I'm thinking about -- some services clearly played along, some apparently didn't. This suggests to me that the government is using pressure and influence as well as clear legal authority, and I'd like to have some idea where the line is between those, so that I can't simply be used.

Fortunately, this is a long-term problem unless I am *far* more successful than I realistically expect. But it's something worth pondering...

[goldsquare.livejournal.com]

I think it would be a positive feature in a product SIMILAR to yours, to allow or permit end to end encryption. I'm not sure how a tool for social communication in Facebook really needs it, though.

It is also worth considering that, if you provide such encryption tools or the embedding of encrypted materials, you'll never know if bad guys are using it too. (Define bad guy for yourself - bad is subjective.)

I suppose you could encrypt logs and other persistent data, and that you could make a good argument for doing so.

If you were building something like the old eRoom tool, or other workplace tools, then I could see how end-to-end confidentiality would be critical. Do you have such a model as your target? Or is this more "Whatya doin'", "Nuthin", "Wanna see a movie?", "Yah" stuff, then your concerns are misplaced.

[jducoeur]

I think it would be a positive feature in a product SIMILAR to yours, to allow or permit end to end encryption. I'm not sure how a tool for social communication in Facebook really needs it, though.

Possibly not, and I don't think I'm going to support it *soon*. But this whole line of thinking started with thinking about how the system might be used for purposes of activism, and I can see activists in, say, China caring about that. (Remember that Facebook is just the initial platform -- I don't consider it a fundamental part of the system.) And as you suggest below, businesses certainly might care.

So I'm at least pondering the end-to-end encryption scenario. I think it's at least a year off, but I'm going to put it on the story list and let it stew. We'll see if it reaches the top.

I suppose you could encrypt logs and other persistent data, and that you could make a good argument for doing so.

Yeah, but the problem is that doing so *truly* securely (securely enough to keep the government out) is a nearly intractable problem. Doing so for the logs (which are mostly write-only) is merely moderately hard; really doing so for the actual conversation data (which needs to be read/write) is really difficult. (I wouldn't have even credited it as possible, although herooftheage's suggestion is plausible.) I can reduce the exposure, but actually making it *secure*, in the technical sense, isn't likely.

If you were building something like the old eRoom tool, or other workplace tools, then I could see how end-to-end confidentiality would be critical. Do you have such a model as your target? Or is this more "Whatya doin'", "Nuthin", "Wanna see a movie?", "Yah" stuff, then your concerns are misplaced.

Unclear. I suspect the initial target is a bit in-between those, just as LJ is -- that is, not completely trivial, but usually not earth-shaking. But business use is a very real and plausible long-term possibility that I have on the back burner. Frankly, I think that if this thing really took off in the popular sphere, people *would* start using it for business, just as they've picked up IM (there are obvious use cases, and business is getting more comfortable with hosted services), and providing additional capabilities for workplace is a very real possibility.

So we'll see. As with most of these upfront discussions, I'm mostly organizing my thoughts at this point. It's going to be a long time before this stuff matters, but I like exploring the problem space a ways in advance. (If nothing else, it tends to make me think of new possibilities of where the product might eventually go.)

[dsrtao]

What people say in public places is going to be recorded. CommYou is largely going to be public places, yes? Will there be any private conversations? Not without end-to-end crypto.

What you can do that would make *me* feel better:
- when the owner of a conversation deletes it, everything should go away except a log entry saying 'owner deleted conversation'.
- logs should be minimal. You can't turn over information you don't have.

[mindways]

Brainstorming additional measures that would be reassuring, if you wanted to go there:

- To only accomodate subpoenas and such made via the US legal system. (ie: if a representative of some foreign government calls you up and tries to badger you into getting some conversation's info, the response would be "I'm sorry, no".)

- To explicitly say "while we don't provide tools for it, if you want to encrypt your conversation, feel free"; perhaps providing pointers to some simple tools therefor.

- To provide support for some sort of client-side encryption integration.

- For those "by word-of-mouth invite only" conversations, support encryption of whatever conversation data is stored in the DB. I.e.: the actual passphrase for the conversation is never stored on your servers [just a one-way hash of it for "you can view this" authentication], and is used as a key for some form of encryption pre-storage and decryption post-retrieve. This is, admittedly, of limited benefit - it wouldn't help if you became legally required to capture the information on an encrypted conversation, since it would be trivial to change your code such that you stored that incoming key the next time someone used it. But it would mean that no-longer-active conversations of that sort couldn't be accessed (since nobody would be sending the key over anymore). It would also provide a little bit of extra protection vs. hackers (regular or state-sponsored); someone simply grabbing a copy of your database wouldn't be able to access those conversations without also doing the above sort of monitoring.

[jducoeur]

To only accomodate subpoenas and such made via the US legal system. (ie: if a representative of some foreign government calls you up and tries to badger you into getting some conversation's info, the response would be "I'm sorry, no".)

Good point -- I'd pretty much been intending that anyway. Indeed, one of the reasons I'm thinking about keeping the company closely held is specifically so I can tell China to buzz off if need be. It's hard for a public company to sacrifice that large a market (it's the thin end of the wedge for Google in terms of evil, far as I can tell), and I'd like the ability to do so if principle requires.

To explicitly say "while we don't provide tools for it, if you want to encrypt your conversation, feel free"; perhaps providing pointers to some simple tools therefor.
To provide support for some sort of client-side encryption integration.

Interesting. I hadn't thought about that, and it has some important implications, but it's worth thinking about. (In particular, it implies that there needs to be at least API access that provides a completely unmodified data stream, which is not otherwise obvious given data sanitization issues.) I may need to add that one to the story list, because it's a neat and useful idea.

For those "by word-of-mouth invite only" conversations, support encryption of whatever conversation data is stored in the DB.

An interesting middle-ground suggestion. Hadn't occurred to me, precisely because it's a fairly weak protection, but you're right that it has some benefits. Worth considering, anyway -- thanks!

[jducoeur]

CommYou is largely going to be public places, yes? Will there be any private conversations? Not without end-to-end crypto.

While technically true, it's rather oversimplified. Privacy is a spectrum, not a simple black-and-white. It's all about who you're trusting, for what, and how much. The issue for me is figuring out what I'm going to provide in that regard, and setting expectations appropriately.

when the owner of a conversation deletes it, everything should go away except a log entry saying 'owner deleted conversation'.

Reasonable, but plays very closely into the ownership question. I still haven't decided how I'm going to resolve that particular tension. (Deleting conversations is a medium-high story, but still a ways off yet in absolute calendar time.)

logs should be minimal. You can't turn over information you don't have.

A reasonable point. Fortunately, also probably a moot one: I probably just can't *afford* extensive logging -- it tends to be far more trouble than it's worth once a system is past initial debugging...

[laurion]

Hmm. For some reason, Ghandi comes to mind. "Be the change you want to see in the world". Your policy should reflect your own values and stance on privacy, and while the Feds may have the ability to abrogate that, you should make it as easy as possible for them to follow along with your philosophy, and as difficult as possible for them to do otherwise.

[jducoeur]

A nice way of looking at the problem. I'm not quite sure what it means in practice, but worth reflecting on...

[fairdice.livejournal.com]

Who's hosting your data and your backups? If you don't have physical control, then it's unlikely that whatever policy you develop will be the limiting factor. Even if you do have physical control, you don't have a legal department. So you should assume -- and certainly all of your users should assume -- that anything that you (=the admin) can read, the FBI can read too, if they want to.

If you want to encrypt private conversations such that only legitimate readers have decryption keys, more power to you, and you should advertise as such (eg "if you lose the key, the data is gone, and we have no way to recover it").

[jducoeur]

Who's hosting your data and your backups? If you don't have physical control, then it's unlikely that whatever policy you develop will be the limiting factor.

Sad, but a very good point. It's going to be some time, at least, before the company is big enough to run its own servers.

If you want to encrypt private conversations such that only legitimate readers have decryption keys, more power to you, and you should advertise as such (eg "if you lose the key, the data is gone, and we have no way to recover it").

This would be lovely in principle; unfortunately, I don't think the mass-market web has the necessary infrastructure yet to do this easily.

That said, it's worth thinking about how that could be encouraged. For instance, I could easily see working with Firefox plugins to support genuine end-to-end security. That's a long-term story (that is, not in the next year), but potentially a very interesting one, and there's nothing technically *hard* about it -- it's just a lot of work...

[herooftheage.livejournal.com]

If it were me, what I'd do is this (with handwaving because I don't actually know how the details work): encrypt everything and hand keys to whatever groups get to read the lists. Make it in such a way that you simply cannot grab a key yourself - for example, have some off-shore key company hold onto them for your users. You also can't write code to allow you into his group willy-nilly. Perhaps the same off-shore company does the group-assignment with verification function. This is going to cause you some amount of merry hell when it comes to bug fixing, since you only get to see the encrypted version of other people's data streams, but your stuck there. You also need a way for your customers to verify that its the off-shore company doing the security checks.

Now if I understand things correctly, once the government comes calling, you aren't allowed to go telling your customers to run for cover. However, if they care, they can see it for themselves, once you are forced over into switching into some other way to do the key checks, and then they can make what inferences they would.

Possible...

[metageek.livejournal.com]

This would be possible, though you'd need a Java applet to do the crypto, which leaves out users who don't have Java for one reason or another. (In theory, you could use JavaScript, but the performance is likely to be lousy.) With the local-storage APIs, you could store the keys locally, so that you don't have to hold on to them yourself. You could even provide a way for the users to distribute them out of band, so you never see them at all.

Of course, the problem then is that you're exporting crypto software, which is still regulated.

Re: Possible...

[herooftheage.livejournal.com]

Also, you have to prove to the end user you don't have a secret back door into his security, or that a later update of the software doesn't add one. I suspect that means supplying source code and the path for turning source code into the compiled version, so the user can check to see that the executables are a direct result of the source.

Re: Possible...

[metageek.livejournal.com]

That would be good, but you could go a long way without that.

Of course, all the browsers include public-key crypto, to implement SSL; in theory, they could expose that to JavaScript. Um...<dig, dig>...Mozilla does that, but it looks like it might not let JavaScript encrypt anything; it might be just for signing.

There are various all-JavaScript implementations of cryto code, including at least one public-key implementation.

Re: Possible...

[jducoeur]

There are various all-JavaScript implementations of cryto code, including at least one public-key implementation.

Hmm. Honestly hadn't occurred to me -- I wonder how slow it is? The problem at that point is just key management, which is still an issue, since the idea of good browser-side storage is still kind of new and immature. Might be more plausible in a year or so, though...

Re: Possible...

[metageek.livejournal.com]

Yeah, I've seen that there are client-side storage APIs in Firefox and IE, but I haven't looked into them, so I don't know their limitations.

[jducoeur]

An interesting idea, but I think I favor the more user-controlled one instead. There's a long-term story that is percolating out of this conversation, of supporting end-user crypto -- in pretty much every respect, that seems to be the best solution, since it has a minimum of third parties involved.

It's a complex enough problem that I can't just support it upfront, but it's easy for me to mentally sketch the architecture (provided the users have a pluggable browser such as Firefox), and it would provide the users with near-optimal security if they care. (And it's still a good deal easier to implement than trying to manage keys across borders, and means that I am not actually involved in the cryptography itself, with all of its legal complications.)