First off, let's just say that like any part of the web, it is probably impossible to totally protect your data that is published on a Google Map. People can always get access to it at very least by just viewing the data, which you want, and making notes. Screenshots, viewing source, intercepts, and other techniques can be used by the truly ambitious. True data privacy in a completely public page is an oxymoron. Note, I'm not saying privacy on the web is bad or not possible, but we're talking here about displaying data. As long as it's displayed, someone can get at it.
That being said, there are steps you can take to make it harder to get at, to make people work at it.
The most important thing you can do is avoid hard coding any information into the page. That should be fairly obvious, but many people fall into the trap. That means:
- Don't have any code in your JavaScript that uses a specific Latitude/Longitude pair, an address, or anything of that nature.
- Use calls to server resources to plot only the data necessary to display at that moment. Try to verify the origin of the requests to prevent people from scraping. Generating your data on the fly prevents someone from getting all your data at once.
- Obfuscate/compile your Javascript code to make it harder to read.
You can also rasterize your data, or turn it into image overlays. There's a lot of techniques for doing this. This talk by John Coryat is a couple of years old, and was oriented to Maps API V2. However, in it he discusses many techniques that are applicable to V3.
Rasterization makes it difficult to extract the data directly. It can also increase your performance in some cases where you have lots of data.
If you're working with KML, you can distribute the KML to only trusted people to load in their Google Earth instances, but this is subject to trusting them. Any KML used in a Maps API application will be easily findable by someone who can get passed any obfuscation you have.
That's all I've got. Feel free to post any additional techniques in the comments.
No comments:
Post a Comment