27 ms·

>I think it’s safe to say that Google’s AdWords is the dominant advertising platform on the open Web, which means it holds a commanding position in the Web’s fi

by mvn9 6y ago

>I think it’s safe to say that Google’s AdWords is the dominant advertising platform on the open Web, which means it holds a commanding position in the Web’s finances. That's a very interesting observation. Google will thus prevent a native payment option at all costs, which leaves a huge opening for Brave or another payment provider. (Which is enhanced by content providers being threatened by AMP.) I don't see Google in a very secure position. Their employees nowadays don't seem to care which will become a huge problem once Google has to actually react to a changing market. Amazon is getting product searches and Facebook can take over everything else whenever they want because Google's results don't come from analysing the web but from showing the pages that other people with the same queries are visiting. Additionally, Huawei is forced to setup their own app store. If they have the better TikTok app, and online payment with wechat, the next generation of users will switch. China has so much more developers that a Chinese app store will become the more interesting place for new apps. With Zoom and TikTok, they have shown that they can create competitive apps.

nqzero 6y ago
agree that I see google as vulnerable and the space could move very quickly - for end users, there's no lock-in (compared to eg facebook with the network effect) but is Zoom chinese ?
cheph 6y ago
> That's a very interesting observation. Google will thus prevent a native payment option at all costs, which leaves a huge opening for Brave or another payment provider. Can you elaborate on what a native payment option would entail? How would it be different from non native payment options? How would it be different from crypto or other payment options that already exist?
- mvn9 6y ago
  Like barrenko said in another comment [1]: >Wasn't it that the creators of Netscape wanted to put some kind of payment protocol similar to crypto in the original browser but ran into trouble with the government, can't remember anymore. 402 error was famously reserved for money trouble. You could have one standard, in the same way that webpages are standardized. Then you could use your preferred option on any webpage. It would come with your browser, so no need to install anything. Unlike the Apple app store, you wouldn't have one player controlling everything, so the payment network wouldn't take 30% of all profits. Of course, whatever is feasible as a standard is also feasible as a plugin, or at least, like Brave, as a new Browser, if Google limits the plugin api. The difference is that nowadays, every payment option tries to be the winner, preventing every other player from advancing. With a standard, those fights would be over and users could start paying for everything. I think the biggest difference would be that people would pay for single articles and videos from obscure sources. Nowadays you have to hand out your credit card or register for an obscure payment network like Brave or patreon. People register for Netflix, but not for a blog they visit one time in their life. It's very likely that a webpage and a visitor use different payment options, thus payment is not possible. As a consequence, everything is paid with adverts, like the article states. With a standard, that would shift and the default option would be a clean article without ads. [1] https://news.ycombinator.com/item?id=24177888 https://news.ycombinator.com/item?id=24177888
  - hakfoo 6y ago
    I always thought a sensible approach would have been a sort of "payment tag" that browsers could render directly. Something like <payment name="transactionId"> <amount>30.00</amount> <currency>USD</currency> <ordernumber>123456</ordernumber> <method name="WireTransfer" account="234567" routing="3040567" /> <method name="PayPal" destination="company@company.com" /> <method name="CreditCard" url="https://secure.gateway.com" https://secure.gateway.com" merchantid="123456" /> <method name="Dogecoin" walletid="D0304050600405kgjfd" amount="2600" /> </payment> This would render as a group of buttons representing the payment choices. The browser would pop up an appropriate form-- potentially in an isolated context where the fields can't be sniffed by on-page scripts, perform the remittance, and submit a structure of verifiable confirmation details in the field transactionId when the form was submitted. Since the flow is steered entirely by the user's browser, there's a stronger degree of trust and control; I could imagine, for example, bank-provided plugins that required a seperate authentication before relaying the card details, or more sophisticated 3-D Secure style checking and fingerprinting. The entire PCI compliance and trusting merchants with the card number problems would never have come into play. There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000.
    - cheph 6y ago
      > There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000. If it is so simple, why was it not? Are you suggesting it was purely incompetence of the people who standardized the web back then?
      - hakfoo 6y ago
        While this is a bit of an after-the-fact view, it seems like there was a moment where they basically said "we've got enough tags." Richer and special-case capabilities tended to move into (first) applet platforms like Java and Flash, and later JavaScript and CSS enhancements atop a fairly thin platform. I feel like this was the same stall-out that created "it took until HTML5 before we had a more or less universal slider form control" and "there's still nothing resembling a OS-native dropdown menu or rich-text widget in pure HTML." That time period sort of coincided with the window of a couple years-- when we still had to think about 40-bit and 128-bit crypto offerings, you had to explicitly navigate to a SSL domain to check out, and things like Flooz were still considered a viable idea. Nobody really knew how to take a payment online, so we ended up basically copying the payment from from a mail-order catalog in HTML. A strong "this is the secure and easy way with big clicky buttons" proposal, supported by the leading browsers, would have steered the nascent market effectively.
joshuamorton 6y ago
Google's actually tried a native payment option more than once (Google contributor). Web sites dislike it. Established Web content producers prefers ads to micropayments. There are obviously subsets of the web where this doesn't apply (twitch and YouTube where patreon is common, onlyfans, etc.), but that's almost solely for video and live interaction. Micropayments are, apparently, not what the textful web wants.

by mvn9 6y ago

nqzero 6y ago

agree that I see google as vulnerable and the space could move very quickly - for end users, there's no lock-in (compared to eg facebook with the network effect) but is Zoom chinese ?

cheph 6y ago

> That's a very interesting observation. Google will thus prevent a native payment option at all costs, which leaves a huge opening for Brave or another payment provider. Can you elaborate on what a native payment option would entail? How would it be different from non native payment options? How would it be different from crypto or other payment options that already exist?

mvn9 6y ago
Like barrenko said in another comment [1]: >Wasn't it that the creators of Netscape wanted to put some kind of payment protocol similar to crypto in the original browser but ran into trouble with the government, can't remember anymore. 402 error was famously reserved for money trouble. You could have one standard, in the same way that webpages are standardized. Then you could use your preferred option on any webpage. It would come with your browser, so no need to install anything. Unlike the Apple app store, you wouldn't have one player controlling everything, so the payment network wouldn't take 30% of all profits. Of course, whatever is feasible as a standard is also feasible as a plugin, or at least, like Brave, as a new Browser, if Google limits the plugin api. The difference is that nowadays, every payment option tries to be the winner, preventing every other player from advancing. With a standard, those fights would be over and users could start paying for everything. I think the biggest difference would be that people would pay for single articles and videos from obscure sources. Nowadays you have to hand out your credit card or register for an obscure payment network like Brave or patreon. People register for Netflix, but not for a blog they visit one time in their life. It's very likely that a webpage and a visitor use different payment options, thus payment is not possible. As a consequence, everything is paid with adverts, like the article states. With a standard, that would shift and the default option would be a clean article without ads. [1] https://news.ycombinator.com/item?id=24177888 https://news.ycombinator.com/item?id=24177888
- hakfoo 6y ago
  I always thought a sensible approach would have been a sort of "payment tag" that browsers could render directly. Something like <payment name="transactionId"> <amount>30.00</amount> <currency>USD</currency> <ordernumber>123456</ordernumber> <method name="WireTransfer" account="234567" routing="3040567" /> <method name="PayPal" destination="company@company.com" /> <method name="CreditCard" url="https://secure.gateway.com" https://secure.gateway.com" merchantid="123456" /> <method name="Dogecoin" walletid="D0304050600405kgjfd" amount="2600" /> </payment> This would render as a group of buttons representing the payment choices. The browser would pop up an appropriate form-- potentially in an isolated context where the fields can't be sniffed by on-page scripts, perform the remittance, and submit a structure of verifiable confirmation details in the field transactionId when the form was submitted. Since the flow is steered entirely by the user's browser, there's a stronger degree of trust and control; I could imagine, for example, bank-provided plugins that required a seperate authentication before relaying the card details, or more sophisticated 3-D Secure style checking and fingerprinting. The entire PCI compliance and trusting merchants with the card number problems would never have come into play. There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000.
  - cheph 6y ago
    > There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000. If it is so simple, why was it not? Are you suggesting it was purely incompetence of the people who standardized the web back then?
    - hakfoo 6y ago
      While this is a bit of an after-the-fact view, it seems like there was a moment where they basically said "we've got enough tags." Richer and special-case capabilities tended to move into (first) applet platforms like Java and Flash, and later JavaScript and CSS enhancements atop a fairly thin platform. I feel like this was the same stall-out that created "it took until HTML5 before we had a more or less universal slider form control" and "there's still nothing resembling a OS-native dropdown menu or rich-text widget in pure HTML." That time period sort of coincided with the window of a couple years-- when we still had to think about 40-bit and 128-bit crypto offerings, you had to explicitly navigate to a SSL domain to check out, and things like Flooz were still considered a viable idea. Nobody really knew how to take a payment online, so we ended up basically copying the payment from from a mail-order catalog in HTML. A strong "this is the secure and easy way with big clicky buttons" proposal, supported by the leading browsers, would have steered the nascent market effectively.

joshuamorton 6y ago

Google's actually tried a native payment option more than once (Google contributor). Web sites dislike it. Established Web content producers prefers ads to micropayments. There are obviously subsets of the web where this doesn't apply (twitch and YouTube where patreon is common, onlyfans, etc.), but that's almost solely for video and live interaction. Micropayments are, apparently, not what the textful web wants.