TRUSTe is basically a certification thing, that certifies applications and websites against a bunch of "standards" (http://www.truste.org/pdf/Trusted_Down
Okay, now I've thought about it for 5 minutes I'm starting to realise this may not be so easy.
Major initial issues:
1) time for reviewing software
2) infrastructure (website etc.) -- pretty easy to do
3) maybe need lawyers?
4) my standards are pretty high, maybe it's impossible to meet them without getting in potential trouble (i.e. need lawyers)
What does The Internet think?
Profile
![[info]](http://p-stat.livejournal.com/img/userinfo.gif)
liedra- Catie
- liedra.net
Comments
The reason I say that is that I think the actual "certification" part is largely BS. The glue holding the scheme together is made of lawyers, not technology. I.E., Microsoft is passing the security buck to a third party to TRUSTe. Similarly, application and Web vendors also get to abdicate responsibility, because they will rely on TRUSTe's certification: if they get it, then they're "independently verified" and don't have to do any extra work.
So TRUSTe has to put on a good "magic tricks" show to convince people that its certification process is valid, but ultimately its job is to take the blame when something goes wrong.
BTW, I can out-cynical you. The point of TRUSTe may be to be UNsueable. It would be ideal if Microsoft etc. could pass the buck to a legal entity which looked like it was suable but effectively wasn't (e.g. because it didn't have enough assets to be worth suing). Although maybe that's what you meant anyway.
I guess I went too far suggesting that the requirements for certification don't matter. They do matter, they're just secondary to the above two requirements.
But really only requirement (b) is necessary in order to provide value to companies (which I cynically suggest is a good motivation for them to undergo certification). To put (b) another way, Web sites only started implementing support for Firefox when it became big enough to matter, which started a virtuous cycle where more people became aware of Firefox, which created more Firefox users, who created further awareness, etc. Catie would need to become the Firefox of privacy certification.
Because that sounds useful to me, but it also sounds like it needs lawyers and stuff. It also seems a little different to what TRUSTe is doing, because that's more about websites having the competence at carrying out what they say they'll do (keep your data safe). At least that's what I guess after a brief glance?
elfishski: "trying to pull a fast one where they will claim to own your IP later" -- is what they call IP spoofing?
You could construct a general public EULA and be the head of the Free EULA movement!
PS I wrote the opening overture, I just have to get the Robocop solo "My Heart of Metal" pinned down.
PS. I'm a lawyer! Pick me!
How's that passive-aggressive Facebook app coming along?
I think if I, say, get some backing from a university or something (i.e. don't look like a company out to make a huge profit or something) then it could work :)
One model is to delegate trust, think the SSL certificate example mentioned by
Another is to provide a framework for developers and users to make own trust decisions. I'm thinking something like Creative Commons except focused on clarifying EULA's from an informed consent focus rather than (or in addition to) a use restrictions one. Of course there's an element of trust involved this way as well, but it's a lesser one because the EULA is saying "you should trust me, liedra will explain why" rather than "just trust me, liedra will vouch for me". If you followed the CC model of supplying templates to developers you might need less lawyers too, as you could offer premade EULA's with no implied warranty (I think this is the way CC works anyway?).
I think though that you could incorporate the second into the first though, and have "template" styles that will let companies write nice EULAs easily, then have a second stage where they are essentially audited for compliance with my standards.
I guess the problem I see with the first model is that liedra and the user might have different ideas about what types of software behaviour are good/bad. For example I might be happy to install software that pops up ads or transmits anonymous usage data, so long as it doesn't log my keystrokes or send a list websites I visit etc. However if liedra decides this particular software is bad I won't be given the opportunity to make a judgement about whether it's acceptable to me.
I could substitute a labelling system here for words but that could confuse things a little. Or have profiles for different "types" of certification that users might be particularly concerned about. (Not sure on the latter, that'd be quite complicated I think... heh.)
Another thing that could be done is set up profiles for the users, e.g. rorted likes software with conditions A B C but not D E F, and some how when rorted installs an application it checks against the database and sees if it fits rorted's requirements. However, that's less likely to be picked up because it either requires extra coding on the company's part or some sort of software app that sits running all the time waiting for you to install an application. It'd be nice to just avoid that and have a thing that identifies it immediately at the place of download or purchase.
The user profiles idea seems like the ideal solution as users would only need to decide once about each type of behaviour. I was thinking of something like this earlier and came to the same conclusion as you did about its feasibility. In a perfect world the OS/package manager would include an interface which warns of software which doesn't comply to the users profile/uncertified software when the user tries to install, but I can't see how that could be implemented without universal acceptance of liedra's certification system by everyone at the same time. What you've suggested above seems like the best compromise for the time being :)
Think of your certificate as being made up of up to 5-6 (more gets seriously confusing) badges, each for a specific type of application behaviour. One such badge might represent the harvesting of information, another the sharing of information with 3rd parties, and a third "other" concerns.
Giving the earlier example, the first badge might be yellow (information is harvested, but anonymous), the second yellow (3rd parties get information, which would normally spell a red badge, but since the info is anonymous, it's all good), and the third one red because no-one likes their dog killed (I hope).
The hard part would be to come up with a scheme for how to judge a piece of software in all those categories, and how the categories influence each other. Being colour-coded like that, you can see at a glance whether or not an application looks dangerous or not, and you can still provide details about why you judged the way you did.
Since the app above might be ok for you, you might not want to have a red-yellow-green labelling system. If you go for a red-green-"green with sparkly bits" kind of labelling system, your app would look reasonably good (except for the killing of dogs). Anyway, the point is that the way you represent your score is important.
I've had the opportunity to watch parts of a security certification process from the receiving end, i.e. our in-house software was meant to be certified. A large number of the standards you have to pass is pretty stupid, truth be told. But the real money-maker in the business is that you charge for each version of the software that's being submitted for review. Not only does that mean that your next release needs to be reviewed for money, it means that if your app fails the review process and you modify it to change that, you pay again.