There is no way for the user to verify that the payment details are indeed sent over HTTPS. I wouldn't want to enter my payment details in a form like that.
Yeah, we require that people use SSL on the payment pages they serve.
... And yet, despite that, it's not quite a clear-cut situation. When you enter payment details on a site, checking for HTTPS in the address bar is just a heuristic -- you're (mostly reasonably) assuming that "the payment form is served over HTTPS" implies "payment details will be submitted over HTTPS". Browsers try to help here (with warnings for HTTPS -> HTTP form submission), but a poorly implemented site could easily leak information, and you couldn't tell in advance unless you audited all the HTML and JavaScript.
The Stripe Checkout -- which prismviz is using -- always submits details over SSL (of course), but we additionally require websites to serve the enclosing page over SSL because it's both more secure and what users expect.
We rolled out some code recently to more effectively prod users that aren't using SSL in production to implement it. This helps a bit, but it'll always be possible for a weekend project to go live without having crossed every t. Either way, people tend to do the right thing here pretty quickly, since -- as this thread shows -- users complain if they don't.
Or they could have replaced the entire Stripe JS with custom JS that presents a similar-looking dialog that submits the CC data to a third party (possibly also submitting it to Stripe to avoid detection).
Hey yeah so that's the default out-of-the-box Stripe payment solution. Wish I had more time to setup something more familiar like paypal. But got rejected from app store a few days ago and wanted to release this weekend.
also, not sure how I feel about charging for this in general. Figured I'd try as that was the original app store plan.
Here's a free link for HN types though:
prismviz.com/download/hackernews
1) When I first opened the app, my eyes were focused on the central area where the visualization would appear. So, I completely missed the "Working..." text at the bottom[1] and thought it was frozen for a second. I would suggest moving that higher up.
2) It doesn't work, at least not for me. I've opened and quit it multiple times, waited for stretches of fifteen minutes, etc. Nothing. And I have less than 1,500 messages - I've had this iPhone for exactly a week.
sorry to hear its crashing on you. I'm more of a webapp guy so haven't had a lot of success debugging my way through apple's objective-c libraries yet. In general, the backwards compatibility of the 10.8 sdk is pretty unreliable so it definitely works best if you're on mountain lion.
Imagine if this was actually created by the NSA (I mean, naming it Prism seems too obvious to be true), and we're all just falling into it's aesthetically-pleasing honeytrap.
Or suppose the company that built it were party to a data-sharing arrangement for the purposes of marketing. This is a weakness of SaaS in general. I remember not too long ago when ZoneAlarm would ask me if I wanted application X to access the internet, usually I'd think "WTF for?" or "I'll update manually, TYVM."
Do you have a way to download my entire iMessage history including content? I don't care about who I chatted with (I already know the answer to that) but what I would like is a text-format archive of the content of all the texts, for sentimental reasons. My own texts, so no privacy issue here. That would be a really great app in fact, if you are open to pivoting...
Also does this work in cases where the backups have been pretty spotty?
There are several desktop applications for this. I like PhoneView for its other features, but you can dump full conversation history as text or cvs or PDF too:
Great app, however a big bug that breaks visualisation for me in the UK is that messages from 07123123123 and +447123123123 appear as separate contacts (i.e., one number has the contact name, the other shows as the number with the country code prefix), even though iOS treats them as the same.
Have you thought about adding horizontal scale so you can see how many messages/day were sent? Or maybe a quick overview over how many messages/contact were sent in total.
Messaging apps have long been regional due to network effects. In Canada, my friends used MSN Messenger, in the US, AIM. In China, QQ/Wechat, in the US it's mostly been SMS/iMessage or Facebook messages. I've yet to locate a Whatsapp location, but I guess Nigeria is one.
Germany, too, as SMS flatrates got to the market rather late and there was some social networking confusion with the VZ group, slowing down the expansion/adoption of Facebook a bit.
Most smartphone users in Singapore use WhatsApp for general texting too.
On the other hand, WeChat, LINE and KakaoTalk seem to have rather limited audiences here. (Much of the LINE usage between myself and friends is sticker spam.)
chrischen: What do iOS and Android users in your circles use for free cross-platform texting?
Here in Japan it's hard to find anyone under 40 who doesn't use Line for nearly all their messages. The carriers make it extremely expensive for people to communicate with users on other networks so people just circumvent texting and calling with line. I've asked my friends why they use it and they all say because they like the stickers.The market was wide open for a while, it just took some good marketing.
For cross platform we just use Facebook message and SMS. I looked it up, and Whatsapp has very little market share in the US. In China it's pretty dominated by Wechat.
A few years ago, I discovered that iPhones backups are a bunch of sqlite databases (the SMS and call records are, anyway). Once I realized that, I became curious and started digging through old backups just to see what was there.
There is no way for the user to verify that the payment details are indeed sent over HTTPS. I wouldn't want to enter my payment details in a form like that.