Mozilla Introduces Experimental Open Payment System For Firefox OS

hypnosec writes "Mozilla has developed an open payment service API to support app purchases in Firefox OS, and has released a draft version allowing app developers to process payments. Pointing out the drawbacks of the different models for payments on the web that are currently available, Mozilla has revealed that it is looking to introduce a common web API that would make payments through web devices easier and more secure while being flexible and retaining today's checkout button features that are available for merchants. Partly based on Google Wallet, Mozilla's WebPayment API will remain open to ensure that it is used by a wide range of payment service providers. As a first step towards this, Mozilla has introduced the navigator.mozPay function, allowing web apps to accept payments."

Comments

More Data

[Anonymous Coward]

Not only does every website want me to create a profile and stores all my purchase details (email, phone, address, credit card) for *my convenience*, the software I use wants to do it to. Windows 8, Ubuntu (I'm not sure. Does the software center remember your info?), many cell phones, every app-store with punchable software, pay-to-play games, and now even Firefox.

I hope they protect access to prevent your kids from buying things without permission. I hope the data can't be accessed from any website based exploit.

Re:More Data

[Anonymous Coward]

I agree, I do not trust websites and these devices enough yet to place my sensitive info on them, it's still like the old wild west out there. Don't put your credit card information on your kids devices, to keep control of this, I sideload any apps onto my kids devices.

Re:More Data

[Mike Frett]

As an Ubuntu user (Xubuntu), I can answer your question. I've never had to fill anything out to use the OS, but if you want to buy something from the Software Center, you need a Launchpad Account, not so bad really; if you're writing bug reports anyway. Afterwards when you buy your Software, you can have the site remember your info. I always choose not to, you'll need to enter it again if you buy something else. But that's all, nothing at all needed to get the free software or use the OS. =)

I understand what you're getting at though, I have about three pages of login info for websites at my Desk. It's a hassle really, especially if you have all different Passwords; as you should of course. I probably wouldn't mind a single, universal login for everything Internet related that rotates the password every so often. Which probably exists, but I'm unaware of it.

Re:More Data

[hairyfeet]

You ain't the only one AC, I have gotten to the point that if a site doesn't support paying through Amazon I don't buy from them as i'm tired of having so damned many places having too much data. I've had my card replaced something like 3 times in the past 2 years because of some dumbass at some website screwing the pooch and I'm just sick of it.

And i'm not giving the OS jack shit, Ballmer can jerk off at the thought of a 30% cut of all software all he wants I'm following my business customers and hanging onto win 7 like a drowning man hanging onto a log, hopefully by the time 2020 rolls around the board will punt Ballmer like a 30 yard field return and we can has some sanity brought back to the desktop. Until then they can all get stuffed as far as I'm concerned, i'm a customer NOT a walking ATM for them to try to squeeze more sales out of.

Javascript apps and payment

[loufoque]

How do you prevent an user from trivially modifying the Javascript in the app to not require payment?

Re:Javascript apps and payment

[Anonymous Coward]

I guess there pushing for this DRM module thing in the W3 standards :'(

Re:Javascript apps and payment

[Mythmon]

How do you prevent a user from trivially modifying a normal, compiled from C installed on my desktop app such that it does not require payment? In the end, you can't. The mechanisms that are effective in this case are the same mechanisms that can be used in JS.

Re:Javascript apps and payment

[nametaken]

Presumably your postback handlers at the server aren't going to validate a payment for [zero dollars as converted from the price point arg].

In any case, no payment schema allows the client to change the price without screwing up a signed request or failing validation at the server... this was considered somehow.

Re:Javascript apps and payment

[loufoque]

Modifying x86 or x86-64 machine code embedded in COFF or ELF is slightly more complicated than modifying Javascript source.

Re:Javascript apps and payment

[Anonymous Coward]

Think about your average PHP programmer. Then realize that half the PHP programmers are worse than that. Then stop presuming.

Re:Javascript apps and payment

[icebraining]

You don't need to modify the file, just the code in memory. And it's not that hard for most software, otherwise we wouldn't need layer upon layer of protections, like DEP and ASLR.

Re:Javascript apps and payment

[Anonymous Coward]

Yeah, that's not how it works buddy...

Re:Javascript apps and payment

[Jane Q. Public]

"How do you prevent an user from trivially modifying the Javascript in the app to not require payment?"

I was wondering this myself, and I don't think any of the replies so far actually address this issue. In Mozilla's example, they are using JavaScript to create a "JWT", but this is necessarily exposed in user-accessible code, and I do not see how it can be called "secure". They give lip-service to two-part authentication but don't then go on to explain where the other part comes in, which leaves me dubious.

Further, what is to prevent someone from modifying the JS at the "postback" URL to capture the return response? It would seem to me that this alone could compromise security, if it isn't being addressed.

Maybe it *IS* being addressed... but if so, their brief description certainly does not hint at how.

Web Payments not just Mozilla initiative

[msporny]

Hi, I'm the chair of the Web Payments group at the World Wide Web Consortium (W3C). Just pointing out that the Mozilla mozPay() API is part of a greater push in the standards community to make payments a core part of the Webs architecture. This includes buying/selling digital goods, donations, crowd-funding, all the way to equity and loan-based crowd-financing for start-ups. Note that the mozPay() API is centralized, which even folks at Mozilla will tell you is not ideal. The eventual goal is to create a decentralized payment architecture that is designed for the Web from day one. We plan to put these advanced financial tools into the hands of all Web developers so that anyone with a website or blog has access to this open financial network.

You can read more about the PaySwarm standardization work here, which is mentioned at the end of the Mozilla mozPay() blog post: https://payswarm.com/

The first commercial implementation of these specifications launched three days ago: http://blog.meritora.com/launch/

If you're interested in following what's going on, join the Web Payments group at W3C: http://www.w3.org/community/webpayments/

Re:Web Payments not just Mozilla initiative

[Anonymous Coward]

HOLY CRAP! a talking chair!

Just because the wallet is near you when people sit on you. Does not make you entitled to any of the money.

Re:Web Payments not just Mozilla initiative

[WrecklessSandwich]

HOLY CRAP! a talking chair!

Quick, someone introduce Clint Eastwood to him!

Re:Web Payments not just Mozilla initiative

[stacat]

Note that the mozPay() API is centralized, which even folks at Mozilla will tell you is not ideal.

In what sense is it centralized? Locked to a single payment service provider?

Re:Web Payments not just Mozilla initiative

[ArcadeMan]

Whatever you guys do, make sure it's not yet another USA-only thing.

Re:Web Payments not just Mozilla initiative

[msporny]

The mozPay() API is built so that Mozilla has a whitelist of organizations that are allowed to be vendors. You have to get permission from Mozilla to get on that list, and that's not very Webby. That said, Mozilla will be the first to admit that this isn't ideal and that they want to move toward a more decentralized solution. They designed it this way because decentralized payments is a really hard problem and they didn't have time to solve it and launch FirefoxOS at the same time. Luckily, we (Digital Bazaar and other folks at the W3C) have been working on decentralized payments for years and have a working solution that we're coordinating with Mozilla on trying to find a way to get it integrated with the mozPay() API.

Re:Web Payments not just Mozilla initiative

[msporny]

PaySwarm is currency agnostic and is designed to support both national currencies and alternative currencies like Bitcoin and Ven.

Re:Web Payments not just Mozilla initiative

[kipsate]

Quoting linked w3.org page:

There are a number non-interoperable solutions today; PayPal, Amazon Payments, Flattr, Google Checkout, Ven, Bitcoin, BankSimple, Square, and KickStarter are a few examples

Obl. xkcd

Re:Web Payments not just Mozilla initiative

[Darinbob]

It's a week late for Aprils Fools Day.

Re:Web Payments not just Mozilla initiative

[Darinbob]

This is great, if Mozilla ensures that no one gets on the list. This will prevent web payment from ever taking off, a net gain for humanity.

Re:Web Payments not just Mozilla initiative

[msporny]

... and none of those are open, patent and royalty-free Web standards. You could argue that Bitcoin is such a beast, but it is more of a financial protocol and currency wrapped into one. PaySwarm will eventually support Bitcoin as a currency (along with hundreds of other currencies), so there is no real conflict there. Sorry, but this is Slashdot. If you're going to link to XKCD, you should at least make sure that what you're linking to is a good analogy. :P

Re:Web Payments not just Mozilla initiative

[soundguy]

A word of warning - you don't get to call it "open" if there are ANY restrictions on usage. US currency clearly states that it is "legal tender for all debts public and private". That's the model you need to emulate, not self-righteous scumbags like PayPal and Google. Any system that restricts such things as gambling, adult media, sexual services, cash transfers, etc is a closed, proprietary financial system and the world is already polluted with far too many of those. When I can sell porn, poker, hookers, and blow using your system, then we can talk. Not before.

Re:Web Payments not just Mozilla initiative

[dargaud]

I have a question... Why hasn't this been implemented in 95 ? There was a real need for a micropayment system at the time: everybody was talking about it, and then it got more or less replaced by credit card purchases, which took a long time to gain traction and are only use for larger payments anyway. Napster would have been different if there'd been a micropayment option in it !

Re:Web Payments not just Mozilla initiative

[goose-incarnated]

Whatever you guys do, make sure it's not yet another USA-only thing.

PaySwarm is currency agnostic and is designed to support both national currencies and alternative currencies like Bitcoin and Ven.

That doesn't address GP's point - Google Play Store supports alternative currencies and yet still remains US-and-UK-only. What GP (and myself) would like is a system that lets anyone from any country be a vendor. Unless I'm mistaken (IOW, correct me if I'm wrong) your system allows anyone to pay, but not just anyone to receive payment, just like Google Play and countless others? Merchants have to be resident in one of perhaps five countries?

If I'm correct (and I heartily agree that I may not be - perhaps I misread?), then you guys are designing yet another toy payment system only for use for western merchants, in which case you are wasting your time.

Re:Web Payments not just Mozilla initiative

[elucido]

How do you intend to compete with Bitcoin technologically? Bitcoin seems to have every technological advantage over your product.
This is a serious question because lately Slashdot has become very much pro-Bitcoin and for something like micropayments Bitcoin makes more sense than dividing pennies into a fraction of a penny which would be pretty much worthless to most users.

Re:Web Payments not just Mozilla initiative

[elucido]

PaySwarm is currency agnostic and is designed to support both national currencies and alternative currencies like Bitcoin and Ven.

If it supports Bitcoin then I think your idea will be a major success. Bitcoin is the only way micropayments could work for the mainstream because it's deflationary. I suggest you also take a look at Devcoin as well because it seems to be important for what you're working on.

Re:Web Payments not just Mozilla initiative

[msporny]

The PaySwarm specifications allow anybody to implement the specification and interoperate on the network. So, if your country doesn't have a PaySwarm Authority, there is a huge incentive for somebody to launch one in your country.

In our system, anybody (in any country) can become a vendor. At the moment, we only deal in USD, so if you want to withdraw your money, you need a bank that can talk to the US banking system (many international banks can already do this).

The only thing preventing us from branching into your country is a slew of regulations that we have to follow to make sure that we're operating the service legally in your country, using your currency.

So, I think you partially mis-read what we're doing. We only support USD now because we just launched. Eventually, we hope to support all major currencies in the world. If we don't choose to support your currency, somebody else will. Their PaySwarm Authority (the thing that acts like the bank on the network) will allow you to use whatever currency you want to in your country of origin, and it will be up to them if they want to interface with other PaySwarm Authorities around the world.

The bottom line is: The system is designed to make it such that every currency in the world will eventually be supported if there is a profit to be made in doing so.

Re:Web Payments not just Mozilla initiative

[msporny]

PaySwarm will eventually support Bitcoin. However, that is a separate issue from the one of doing micropayments. They're two orthogonal concerns. They do have a slight bit of overlap, but not enough to tie the design either of the solutions to one another. +1 to Devcoin. You might also want to check out Gittip: https://www.gittip.com/ We can support both with PaySwarm (since PaySwarm is currency agnostic). It's also fairly trivial to setup something like Gittip using PaySwarm (recurring payments). More here: http://blog.meritora.com/launch/

Re:Web Payments not just Mozilla initiative

[msporny]

Things that are legal in most states: gambling, adult media, cash transfers. Things that are illegal in most states: sexual services, selling hookers (human trafficking), and blow (drug trafficking). Payment services tend to avoid gambling and adult media because there is a huge fraud problem with them, and in the grand scheme of things, they're not as profitable as the vast majority of other "safer" transactions. Cash transfers require a huge amount of money to get a license to operate in all 50 states in the US. If you want to do something illegal, use Bitcoin or cash. If you want to do something cash-based, we're working on a Bitcoin-like alternative, but it's not a high priority. More on the commercial service here: http://blog.meritora.com/launch/

Re:Web Payments not just Mozilla initiative

[msporny]

The short answer is that there aren't a lot of people working on the problem. There are 7,000,000,000+ people in the world. There are 60 people in the Web Payments Working Group at W3C, of which only around 10 are actively working on the problem. It's a hard problem and there aren't that many programmers, systems engineers, standards makers, writers, bloggers, lawyers, etc. that are willing to put in the hard work to solve the problem. If you think this is an exception to the rule, you'd be wrong. There are only around 40 people really working on HTML5... and that work reaches over 1.5 billion people.

We've been working on the Web Payments stuff for 7+ years and I've always been kind of floored at how quickly most tech folks backpedal away from creating a truly revolutionary financial system on top of the Web.

If you're interested in lurking or especially helping, please join the Web Payments group... we need every helping hand that's available: http://www.w3.org/community/webpayments/

Re:Web Payments not just Mozilla initiative

[msporny]

Bitcoin isn't a technological competitor, it's a currency. Bitcoin isn't going to be the last currency of its kind, there will be many Bitcoins just like there are many currencies today. Each one is fit for the group of people that uses the currency. The PaySwarm standard is a financial protocol and is thus currency agnostic. We plan to support Bitcoin, and Ven, and a variety of other currencies.

You could argue that Bitcoin is also a protocol, but that is where Bitcoin is fairly weak. Instead of building Bitcoin on the Web's architecture, it was decided to invent a new protocol. While the new protocol works, it's not very Webby, and because of that there is a great deal of heavy lifting that needs to occur to participate on the Bitcoin network. The PaySwarm work builds on top of the Web (HTTP, HTML, RDFa, JSON, etc.), so the financial protocol lives as a core part of the Web. It also doesn't conflate currency with protocol, so it's capable of supporting more than one currency, including the one that will eventually replace Bitcoin.

Regarding your micropayments statement, you're conflating the value of a currency with the divisibility of the currency. Micropayments support is about divisibility, not value. The only thing to discuss about Bitcoin's micropayments feature has to do with the latter, how divisible it is, which is (8 decimal places) vs. how divisible PaySwarm is (10 decimal places). It's not a very interesting discussion, I admit. :P

Re:Web Payments not just Mozilla initiative

[goose-incarnated]

Thank you for that informative reply - I wish your efforts with payswarm take off, if only to ensure that non-US merchants can finally get paid

I ain't paying

[Mister Liberty]

anything for stuff that wants "acces to your private date", "access to
your harddrive", "access to the network" that I haven't got the source
code for.

Re:I ain't paying

[msporny]

The folks working on the PaySwarm stuff believe in data portability, so you own your private data and can take it with you when you leave the system. That's a design goal. As far as access to your hard drive, that's a bit vague - does writing a cookie to your hard drive count? Same with access to the network, vague. Care to elaborate? There are a number of open source implementations of clients now: https://github.com/digitalbazaar/payswarm.js/ https://github.com/digitalbazaar/payswarm-wordpress/ Since it's an open, patent and royalty-free spec, there will be open source implementations of a PaySwarm Authority (the things that process payments and move money around in the network) in time.

Question: Does this count as an in-app payment?

[tlambert]

Question: Does this count as an in-app payment?

Because you could consider a browser an app, would this fall under the purview of the in-app purchase patent that's being enforced out of East Texas?

Re:Question: Does this count as an in-app payment?

[msporny]

It could count as an in-app payment and I have no idea if the in-app purchase patent you're talking about applies, nor am I going to go take a look at it:

http://itlaw.wikia.com/wiki/Treble_damages

Our experience in this area, after looking at lots of patents, is that they tend to be badly written and/or easily easily worked around. We did file provisional patents for the technology in 2004 to establish prior art for the express purpose of ensuring that nobody else could patent the technology and that we could offer it patent and royalty-free in a Web standard.

We need to pay for content creation

[A beautiful mind]

The current mostly advertisement supported model that's dominant on the internet is warping how we interact with each other and how we use services - reminds me of a bad mix of Orwell's 1984 and The Matrix (the part where humans are used as batteries).

I'd gladly pay for a lot of content on the internet, but currently I either don't have the option or the pricing is outrageous - scientific articles and newspaper subscription comes to mind as being way overpriced. We need microtransactions and the first step is building the infrastructure to make it possible. Things like app.net instead of surveillance supported services like facebook are the step in the right direction.

Re:We need to pay for content creation

[Anonymous Coward]

That sounds great. In theory.

In reality you'll be seeing ads AND paying too. They'll be gathering all the data about you. AND you'll be paying too.

They're not going to give up anything they've gotten upto now just because you started paying them...

I'll pass.

Re:We need to pay for content creation

[Anonymous Coward]

No, no, no.

We do not have a need to pay for content or its creation. The content makers need to try and make us pay for content, if they want to make a living or a profit from it. So they need to find a business model. Having an API to pay through does not generate any incentive to actually do so. As of now, people are fine with ad-financed services like YouTube.

Re:We need to pay for content creation

[msporny]

PaySwarm, which is part of the Web Payments work at the W3C, supports micro-transactions. All transactions in the system are accurate up to 0.0000000001 of a fraction of the currency specified. See this for more details: http://blog.meritora.com/

Re:We need to pay for content creation

[Kjella]

I think someone should soon start to make a standard form for why microtransactions won't work like we have for SPAM, I mean I've heard this now for a decade now? Two? And it never materializes, I think most of all because each transaction is either a hassle or an invisible drain on my bank account. Pay-per-minute Internet died in favor of flat rate even though it'd probably be rational for those who use it little to have a metered connection, but the simplicity of just paying a fixed sum won out. Ads may be annoying, but I know they won't cost me anything. Broadly deployed microtransactions means you're back getting an "Internet bill" except now you have a zillion sites trying to bill you with all the crap that's going to lead to.

Besides, if you're going for paranoia the micropayment operator will have a spectacular history of your browsing habits since you probably won't bother to - or even have the opportunity to, if they compare personal info - to have independent micropayment accounts. If you block tracking cookies nobody has a clue that I'm the same guy visiting all these different sites (they could try doing it by IP but that's very weak) while if they all charge a cent in micropayments well then the micropayment operator must know that to bill me. And it'll all be tied to a much more real world identity than today. Is this really the privacy you were looking for?

Needs broad multistakeholder standardization

[stacat]

This sounds like a great step forward.

The article says: “Mozilla plans to work with other vendors through the W3C to reach consensus on a common API that supports web payments in the best way possible. After shipping in Firefox OS, Mozilla plans to add navigator.mozPay() to Firefox for Android and desktop Firefox.”

I would add that those discussions at W3C should not only include “other vendors”, but also other stakeholders, internationally. This is a way too important topic to be in the hands of “vendors” alone.

Where specifically in W3C is this going to be addressed?

Re:Needs broad multistakeholder standardization

[msporny]

We are building the technology out in the open, transparently. Anyone can join the group. There are no fees, there are no prerequisites for joining. You can read the minutes from every one of the design meetings, and even listen to the audio here (we record everything): http://payswarm.com/minutes/

Here's an example of one such meeting: https://payswarm.com/minutes/2012-07-10/

Why design the financial system in this way? We need to show people that, unlike the way our current financial system is developed and run (behind closed doors), that we're taking a radically new approach to building the basis of the financial network that we hope all of humanity will use. This financial network is open and decentralized, like the Web.

If this interests you, I urge you to join and lurk (or preferably, participate): http://www.w3.org/community/webpayments/

Re:Needs broad multistakeholder standardization

[Anonymous Coward]

Good luck with that. You appear to be more than slightly out to lunch, despite what slashdots generally anti establishment groupthink sways.

Re:Needs broad multistakeholder standardization

[stacat]

We are building the technology out in the open, transparently. Anyone can join the group. There are no fees, there are no prerequisites for joining. You can read the minutes from every one of the design meetings, and even listen to the audio here (we record everything): http://payswarm.com/minutes/

That page looks like the group may be no longer as active as it used to be. :-(

Re:Needs broad multistakeholder standardization

[msporny]

We put the meetings on hiatus until we got the commercial implementation released to the public. We did this just last week: http://blog.meritora.com/launch/ . We plan to start having meetings again within a month or two.

Decentralized Payment Systems

[Anonymous Coward]

Where does VISA stand? Bueller?

Re:Decentralized Payment Systems

[Anonymous Coward]

On the edge of a very tall, very dangerous-looking precipice, just barely able to avoid falling (for now).

But does it run...

[TeknoHog]

Bitcoin?

Re:But does it run...

[msporny]

PaySwarm is currency agnostic, so it can support all national currencies, as well as alternative currencies like Bitcoin and Ven. We don't have Bitcoin support in there yet, but it's on the roadmap and we hope to sooner than later. There are regulatory issues that we have to work through. More here: http://blog.meritora.com/

Full Circle.

[ma1wrbu5tr]

It seemed like it took forever for Firefox 1.0 to be released back when I was using Firefox .8 and .9. I remember people sarcastically complaining numerous times in the forums back then that the developers were trying to create an operating system and not a browser. Well, here we are a little over 10 years later talking about Firefox OS's new payment system. I wonder how much, if any, of that source code from the pre-one-point-oh release is still in Firefox today. Is there any of it in FFox OS? I know I sure never thought there would be a market for a Firefox OS back in 2003. Kudos to the mozilla team.

Re:Full Circle.

[BitZtream]

Two things.

XPCOM is still in there.

There isn't a market for FirefoxOS today, so its not like anything changed from 2003, or hell, even the 90s.

This is just another example of Netscape employees doing whatever random thing they feel like working on rather than focusing on something coherent. Mozilla will die the same painful slow death that Netscape did. The reason Mozilla exists in the first place is that all the shitty Netscape devs needed somewhere to go work after the first one fell apart when Sun realized how useless they really were.

Re:Full Circle.

[Microlith]

There isn't a market for FirefoxOS today

By what measure?

its not like anything changed from 2003, or hell, even the 90s.

Oh right, the monopoly continues to bite us in the ass.

Mozilla will die the same painful slow death that Netscape did.

I don't see that happening. Mostly because at this point Mozilla isn't being financially strangled by a company leveraging a monopoly.

The reason Mozilla exists in the first place is that all the shitty Netscape devs needed somewhere to go work after the first one fell apart when Sun realized how useless they really were.

Ah, I see you prefer to spew insults rather than say anything of value.

Points at Mozilla

[Anonymous Coward]

Hideki!

XKCD

[BitZtream]

http://xkcd.com/927/

Congrats Mozilla, you officially don't get the Internet any more.

Currency conversions

[stacat]

How is the issue of currency conversions addressed?

Re:Currency conversions

[msporny]

In the beginning currencies will be exchanged at whatever the market rate is, automatically. So, if you are sending USD to someone that only has EUR accounts, the amount will be converted automatically based on current market rates and deposited into their account as EUR. The future plans hope to bypass the currency exchange markets for a more direct model, like Ripple, that doesn't have currency exchange fees that are as high as most international banks utilize today.

Too bad that doesn't apply, there are currently

[Anonymous Coward]

0 open payment standards.

Re:Too bad that doesn't apply, there are currently

[msporny]

Not true: http://payswarm.com/ Also: http://blog.meritora.com/

Re:Too bad that doesn't apply, there are currently

[kcbnac]

I think the AC (Anonymous Coward) was referring to "before" (the first two frames).

Now there is 1.

Fatal flaw

[Anonymous Coward]

Unless this will facilitate truly anonymous payment services, it will achieve no more than pushing around the problem a bit, creating large juicy targets with disproportionate market power (think paypal, visa, mastercard) and enlarged disaster waiting to happen. Extending the sports car analogy in TFA left as an exercise.

Payment required to view this comment

[Anonymous Coward]

Finally a use for HTTP status 402 Payment required!

Another Mozilla project

[Anonymous Coward]

Makes me think of Mozilla Persona, which is their project to unify log-ins (in a better manner than openid, etc). I'm a big fan.

Bitcoin is for micropatments

[elucido]

If you lookup Bitcoin it seems to be all about making micropayments possible. I think Bitcoin might ultimately resolve this problem.