Hi,
I want to create e-cards and have some questions:
I am very grateful for any advice.
Fred
I experimented with Greeting Cards about 11 years ago… Secret Admirer – A Valentine’s Day App – Photics.com …and I'm still considering a followup to that project.
Can I protect the html5 code from data theft?
There's little that can be done technically to stop that. Even if there was some way to stop the person from copying the files, they could simply take a screenshot.
Perhaps you could "obfuscate" the JavaScript code, and then embed your images as Base64, but that's just a deterrent. Also, surprisingly, I just made a video about this… https://www.youtube.com/watch?v=VLZLLXd-bBA …you can add a little bit of JavaScript code to discourage bad behavior.
Where is the best place to host the data?
Personally, I'm thinking of going the app route. I make “Wrapping”, so it easily converts a Hype project into an app. I was thinking of making greeting card apps again, but I'm not sure if they would do well.
Is the data safe from attack? When I offer e-cards to my customers, it must not be a gateway for hackers.
Again, that's why I like the App route. It's less maintenance work, so that nice. Although, there's the app review process. Also, there's marketing, as when I first attempted this project, the demand was not strong.
Customizing the card is also tricky. I don't see a way to make the card personalized when it's an app. I could pull the user name, but that might not be a romantic or friendly greeting. They could send the download code with a friendly greeting, so that's nice. I was thinking it might need some sort of hidden mode. Like, if you have access to your wife's phone, you could download the app and then customize the name / greeting. Leave the phone in a spot with a bow on it. So when they unlock their phone, they see the app. HEH!
I might try again this Christmas.
You could use HTML2Canvas… the following threads might help:
If you combine this with contenteditable and some image uploading as seen here:
… you could produce something running only in the browser with text and image customization.
At a high level overview, Hype's HTML5 output results in a pretty vanilla web page, so nearly all questions asked about Hype-made e-cards apply about the same to web pages/sites in general.
Web pages are constructed by downloading individual files. Web browsers allow for viewing the source HTML and all requested files. Therefore it is trivially easy on normal web pages for someone to download and repost or simply link to your assets. This is how the web has been since it was created, and how it exists today. Overall this is feature of the web, not a bug. This is a problem nearly every creator thinks about, and yet at the end of the day 99.999% of them come to the conclusion it is not worth worrying about.
About all you can do is obfuscate things to make it harder for folks to get at data. This also usually make building your own content harder to produce. Ultimately if a computer needs to know how to build a webpage, then adversaries can ultimately do the same thing and copy your content. There's always even lower tech solutions that can be employed to copy your content like screenshots or even camera photos ("the analog hole").
It is usually not worth worrying about because:
There are non-technological solutions to deal with this instead, such as takedown notices and copyright lawsuits. You can also shame folks on twitter, if need be (and you have reached out to them privately first).
All that said, many e-cards do not use any interactive elements at all. If your e-card plays more like a video, then you may want to consider using a video format or animated GIF instead. In Hype, see the File > Export as Movie menu for the options here. This means you can share an individual file, and extracting individual elements is basically not possible unless someone takes the time to mask out backgrounds and such. As an individual file instead of a webpage, concerns like where to host or keeping your servers free of malicious code become much less of concerns.
But to answer the other two questions, going an HTML route:
A lot of e-cards are sent by email with a link to the interactive page. This would be hosted on your web server.
It is responsible to think about this question.
Most competent web hosting companies run scans on hosted content to help make sure that stuff hasn't been injected into the page. Generally if you are just posting static HTML content and assets you don't need to worry about your content being attacked. There's of course tons to this topic and tons of different attacks and threats, but probably not worth worrying about at your scope.
If you're more curious about the topic, ultimately I recommend taking courses about the fundamentals on underlying web technology and computer security.
Ultimately though we get questions like this frequently and I believe that often the concern overrides the threat potential. It is better to focus on making great stuff 
.
What also can be an idea is to use a single sprite sheet (a big image with all your images merged into one), and then position it with CSS. Although it will never 100% stop someone from just cutting out the images, it can be an extra barrier.
That's a pretty big speed bump. 
Also, I thought of this later — if you go the app route, you can use the app to add a bit of security. Again, it's just more deterrents, but if you set it up so that the App and the Web code depend upon each other, then it becomes more difficult to separate the two. That's pretty much how Widgets progressed, as eight of the widgets simply won't function as just web code.
Personally, I would word this differently. It is a concern, and it is part of publishing digital content. Yet, that shouldn't be a reason to stop a project. My GameSalad book was very popular. It was also… how should I say… distributed in not permitted ways.
If I let that discourage me, there would not be a Hype book, and that would be sad.
Thanks for all your tips. 
No problem! Just saw that my suggestions are mostly geared towards a static "card" and assume you are after a still image. If it is about customizing a live HTML5 card that needs to be visited on your host, I think that @jonathan had great suggestions and hints! You could use Hype Data Magic to base all customizable features and areas on a data object and store that object in a database. The row ID or a public identified for the row (like md5 of the row ID) could then be used to fetch the data to view specific customization. Either fetch the data or write it directly from the DB into the HTML given a URL GET parameter.
The first row illustrates a user having the GET parameter in the URL is used for server-side rendering and injecting the data into the returned HTML. Hype is also part of the page and both is delivered to the end user. Hype can then use the data directly.
The second row shows the process of a static Hype file in the browser and the using JavaScript to contact an API endpoint. The endpoint then returns data and Hype displays it after a successful request. This would also be viable for the card creation.
