Show HN: Write your Privacy Policy once and export to multiple languages
github.com
github.com
1) Did you consult with any legal entities when creating this? Is there any risk of creating legal jeopardy for people by inferring that they could use a utility like this to create a legally-sound privacy policy without consulting a lawyer?
2) What consumers currently exist for machine output of privacy policies? I can imagine a standardized machine-readable JSON file on all sites (a la sitemap.xml) could be useful for browser utilities to forewarn you about present or absent tenets of a site's privacy policy.
3) Have you considered using something like this as a boilerplate utility for actual lawyers to improve their throughput for creating privacy policies?
4) Have you considered a similar utility for site terms of service? Is the problem different in magnitude?
5) Are privacy policies legally onerous if you do them in multiple languages? Seems like translation arbitrage would be disadvantageous.
Disclaimer
This project does not constitute legal advice and is not to be relied upon or acted on as such. Any material presented here is for general information purposes only and may be out of date, incomplete or not suitable for your jurisdiction. You should seek independent legal advice from a qualified professional to guide your decisions around a valid and complete privacy policy.
I hope that disclaimer is not deterrent. It's simply the truth: For legal purposes, you should never rely on any online resources without talking through this with a lawyer of your choice, if you want to be on the safe side. No matter if those resources are a manual guide or a computer tool.
1) Yes, I consulted with a lawyer for the version in one language which became the basis for this project. Though this has just been the basis, as I said, and things have changed already, and are expected to change in the future. Some kind of regular review of the current version with legal experts may be a good idea. Apart from that, please see the disclaimer that is included for obvious reasons.
2) None. It's as simple as that, sorry! The important use case has so far been using the output to display on websites. But it's obvious that, having all the input available in a structured and machine-readable form, it would be a good idea to also offer outputs in various machine-readable forms and formats. The vision was exactly that something like a "privacy-policy.json" besides your "sitemap.xml" or "robots.txt" could be helpful and an interesting first step towards a larger "ecosystem", which must necessarily exist.
3) No. I just didn't have the time for that, yet. I also don't know if that's really something that lawyers could use or would want to use. But this is definitely an interesting idea that might be worth exploring.
4) The “Terms of Service“ are a completely different beast, I would say. There's probably not much that could be re-used, and the challenges have only minor overlap, although the concept is quite similar in general.
5) You would probably declare one policy to be your canonical version that really counts, and any translations would be for information purposes and assistance only, without legal validity. Turning to the implementation in this project, translations could probably differ somewhat from each other and wouldn't need to be exact 1:1 translations, word-by-word. Languages such as "en" could also be split up into "en-US", "en-GB", etc. -- not just for the purpose of handling small language differences better, but also for the purpose of adjusting this to the jurisdiction.
[1] https://web.archive.org/web/20160603092300/https://www.thene...
How dare you call yourself a hacker! /s
I was considering JavaScript instead, to make this more accessible (to virtually every web developer). But I found server-side to be more effective than client-side. You could argue that the JavaScript module could have been used in Node.js, but then you're back at Node.js vs PHP, where PHP can be regarded at least as accessible.
Anyway, since this makes use of the most primitive and basic language features only, a later rewrite would be trivial.
This project here does not fall into the trap of believing it could change how privacy works on the internet, at least not in the short term. The target audience is rather the developer community, not big corporations and consumers.
https://www.google.com/support/accounts/bin/answer.py?hl=en&...
> Some browsers require third party cookies to use the P3P protocol to state their privacy practices.
Which browsers should this be today?
Maybe time to blow the dust off my PHP binary... Great work!
This could have been implemented in any language, of course, but server-side seemed to make a little bit more sense than client-side and PHP is still more or less ubiquitous.
I think there have indeed been small attempts to do this before, as with W3C's P3P [1]. But they always had the (end) user in mind, and tried to build advantages for the user. As we all know, users don't desperately request something like that, and so the big companies who could have pushed this forward had no incentive to do so.
This project, on the other hand, regards benefits for the user only as its long-term "vision", and the important short-term goals are benefits for developers, especially small teams.
By the way, this library requiring PHP should not be much of a hurdle. It uses the most basic and primitive language features only and requires virtually no tooling. A minimal example could be constructed by writing one single file yourself, including all the individual files of the library and then having the respective method calls.
Regarding the general concept, there's a lot of room for improvement, of course, e.g. more translations, support for additional clauses and topics, fixes and enhancements based on input from legal experts, etc.
Well, the preferences on this subject will probably vary. For me, server-side has been more helpful in practice.
And you really don't have to embed PHP into every project or site that you do. You could build a small internal service that generates the privacy policies in HTML for each project and then include those policies in the individual projects without any additional requirements on the server side.
The solution here is pragmatic and works. You can measure performance, if you think this is really an issue.
It specifies a privacy policy with options using JSON, and then there is a set of (human-written) strings for each language to turn those options into text.
Legal vocabulary contains words that are terms of art which are then bastardized and changed in usage when used in lay discussion, leading to differential meanings.
Let's not even raise the issue of the language having dramatically different meanings and legal effects across jurisdictional lines even if the wording of the text is unchanged. Or the fact that best practices in drafting specific clauses might be changed in a few weeks following the release of new jurisprudence.
Variants of what?
So there's obviously an easy fix to the problems you outline, which are no fundamental problems.
Regarding legal expertise, I or anybody else could go through this with a lawyer next week and have a review, including a "pull request" of required changes, no more than a week later.
For the translation, of course the process was not copying and pasting words into Google Translate one by one and using the result. The translation process has been much more thorough.
As you said, one should probably not use machine translation for any legal-related stuff, at least not in today's state of machine translation.
By the way, I thought that they would mostly do terms for social integrations, such as Facebook like buttons, widgets, etc. This is the thing that got the least focus with the project that I did. So I didn't realize they have 600 modules (whatever they are and do, exactly), as you say.
I want it to be something that I pay for – I’d expect quality, updates as laws change, support if anything goes wrong, ideally some kind of risk sharing, etc.
Developing and drafting things in the open can produce the same level or even higher levels of quality.
Since the project is not a commercial product, though, I don't care what solution you use :)