Payment Request API | W3C

Payment Request API; W3C; 2017-09-21.

  • Adrian Bateman, Microsoft Corporation
  • Zach Koch, Google
  • Roy McElmurry, Facebook
  • Domenic Denicola, Google
  • Marcos Cáceres, Mozilla


WebRTC and STUN for intra-LAN exploration & end-user tracking


  • WebRTC, promotional site
  • Availabilities
    all the browsers that matter

    • Android
    • Chrome (Linux, Android, Windows)
    • Firefox
    • Opera
    • Safari (iOS)




  • RFC 7350Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN); Petit-Huguenin, Salgueiro; IETF; 2014-08.
  • RFC 7064URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol; Nandakumar, Salgueiro, Jones, Petit-Huguenin; IETF; 2013-11.
  • RFC 5928Traversal Using Relays around NAT (TURN) Resolution Mechanism; Petit-Huguenin; IETF; 2010-08.
  • RFC 5389Session Traversal Utilities for NAT (STUN); Rosenberg, Mahy, Matthews, Wing; IETF; 2008-10.

    • RFC 3489STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs); Rosenberg, Weinberger, Huitema, Mahy; 2003-03.

In Jimi Wales’ Wiki.



In archaeological order


665909webrtc WebRCT Tracking; In Bugzilla of Mozilla; 2011-06-21 →2016-01-11; Closed as INVALID

Some droid using the self-asserted identity token cchen; How to Stop WebRTC Local IP Address Leaks on Google Chrome and Mozilla Firefox While Using Private IPs; In Privacy Online Forums; 2015-01→2015-03.


  • Availability
    of the problem (not of WebRTC in general)

    • Chrome of Google
      • Windows
    • Firefox of Mozilla
      • Unclear, perhaps Windows only
    • Internet Explorer of Microsoft
      WebRTC is not available at all.
    • Opera of Mozilla
      • Unclear
    • Safari of Apple
      WebRTC is not available except through a plugin
    • Unavailable
      • Chrome of Google
        • OS/X
        • Android
      • Linux at all
        not clear; not mentioned at all.
  • Blocking
    • Chrome of Google
    • Firefox of Mozilla
      • Production
        • about:config
        • media.peerconnection.enabled set to true (default true)
      • Development

        • Canary
        • Nightly
        • Bowser
    • Opera of Opera
  • API Directory
    • voice calls
    • video chats
    • p2p file sharing


  • Chrome
    default is available and active
  • Firefox
    • about:config
    • media.peerconnection.enabled set to true (default true)
  • Opera
    only when configured, with a plugin, to run Google Chrome extensions


webrtc-ips, a STUN & WebRTC test rig

  • diafygi/webrtc-ips
  • via on-page JavaScript, makes latent requests to certain STUN servers.
  • Firefox 34 → Does. Not. Work.
  • Fails with
    Error: RTCPeerConnection constructor passed invalid RTCConfiguration - missing url webrtc-ips:58


  • Private Internet Access (PIA)
  • Real-Time-Communication (RTC)
  • Virtual Private Network (VPN)
  • WebRTC


In Privacy Online Forums:


  • 2013
  •  Since WebRTC uses javascript requests to get your IP address, users of NoScript or similar services will not leak their IP addresses.

Via: backfill.


  • about:config
  • media.peerconnection.enabled set to true (default true)

Opera is acquired by a Chinese consortium (Kunlun, Qihoo 360, Golden Brick, Yonglian)

In archaeological order

Opera gets $1.2 billion buyout offer from mix of Chinese firms, board recommends deal; ; In ZDNet; 2016-02-10.
Teaser: There is “strong strategic and industrial logic to the acquisition,” according to the software maker’s CEO.

Original Sources


  • Price
    • $1.2B USD
    • 53% above Oslo close 2016-02-04.
  • Consortium
    • media
      • Kunlun
      • Qihoo 360
    • pure-play investment
      • Golden Brick
      • Yonglian
  • Who
    • Lars Boilesen, CEO, Opera
    • Sverre Munck, chairman of the board, Opera
    • Yahui Zhou, CEO, Kunlun,
  • Process
    • For sale since 2015-08.
    • Representors
      • Morgan Stanley International
      • ABG Sundal Collier

Qihoo 360-Led Chinese Consortium Makes $1.2 Billion Offer for Opera; Rick Carew (Hong Kong), Kjetil Malkenes Hovland (Oslo); In The Wall Street Journal (WSJ); 2016-02-10.
Teaser: Bid for Norwegian company adds to a busy start to 2016 for outbound Chinese acquisitions


  • Opera Software ASA, Norway
  • A consortium of Chinese companies
    • Operators
      • Qihoo 360 Technology Co.
      • Beijing Kunlun Tech Co.
    • Investors
      • Golden Brick
      • Silk Road Fund Management (Shenzhen) LLP
      • Yonglian (Yinchuan) Investment Co.
  • Bid (proposal)
    • Equivalently
      • $1.2B USD in cash
      • 71 Norwegian kroner ($8.27)/share
    • Factoid
      • a 46% premium over trading 2016-02-05
      • <quote>When trading resumed on Wednesday, the stock soared more than 40%, and closed up 33% at 65.10 kroner.</quote>
    • Support
      • Board of Directors, Opera Software ASA
      • 33% of the shares
  • Valuation
    • 2016: $690 million → $740 million (range)
    • 2015: $616 million.
  • Consortium
  • Competition
    sources via StatCounter

    • Android of Googleof Alphabet
      • Chrome → 36.8% market share
    • Microsoft
      • unstated products & market share.
    • Alibaba Group Holding Ltd.
      • UCWeb → ~20% market share
  • Market Share
    sources via StatCounter

    1. Something
    2. Something
    3. Safari
    4. Opera (Phone)→ 10.8%
    5. something
    6. Opera (All; Phone, Tablet, Laptop) → 5.7%
  • Background
    • Qihoo is
      • <quote><snip/>in the process of delisting from the New York Stock Exchange after agreeing in December to a buyout by a consortium including its chairman for $9 billion.</quote>
      • makes mobile and PC antivirus software,
      • operates a search engine
        • No. 2 search engine in China
        • Search engine behind Baidu Inc.
      • has a “secure” Web browser.
    • Kunlun
      • a 60% stake in gay-dating app Grindr LLC for $93 million 2016-01.
    • Other acquisitions by Chinese companies.
  • Who
    • Yu Ling, press relations, Qihoo
    • Havard Nilsson, staff, Carnegie ASA.


In The Wall Street Journal (WSJ):

Testimonial Experience With [Attempting to Evade] the Great Firewall of China | Marc Bevand

Mark Bevand; My Experience With the Great Firewall of China; In His Blog; 2016-01-14.

tl;dr → Google employee visits CN; trolls the firewall with some consumer-grade tunnel schemes.


The App-ocalypse: Can Web standards make mobile apps obsolete? | Ars Technica

The App-ocalypse: Can Web standards make mobile apps obsolete?; Larry Seltzer; In Ars Technica; 2015-12-28.
Teaser: Many big tech companies—absent Apple—are throwing weight behind a browser-based world.

tl;dr → Betteridge’s Law; i.e. No.

  • WebApps are a Google-culture thing.
  • And good luck with Apple; they are intransigent in their non-interest.


In (the arbitrary) order of appearance in the piece:



Via: backfill.

Ad blockers: A solution or a problem? | ComputerWorld

; Ad blockers: A solution or a problem?; In ComputerWorld; 2014-01-15.
Teaser: It’s a cause. It’s a curse. It’s just business. Ad blockers take a bite out of the $20 billion digital advertising pie.

; The business of ad blocking: A Q&A with Adblock Plus lead investor Tim Schumacher; In ComputerWorld; 2014-01-15.
Teaser: interview with Tim Schumacher



  • Adblock Plus
    • Till Faida, president
    • Acceptable Ads program
    • Tim Schumacher
      • the founder of domain marketplace Sedo
      • Adblock Plus’ biggest investor
    • Claims
      • Attributed to Tim Schumacher
      • 148 publishers participate in the Acceptable Ads program
      • 90% of participants in the program aren’t charged at all
      • Attributed to Ad Block Plus
        • rejected 50% of 777 whitelist applicants; because of [their] unacceptable ads,
        • the overall acceptance rate stands at just 9.5%.
        • <quote>Adblock Plus claims that about 6% of all Web surfers in the U.S. run its open-source software, mostly in the form of Google Chrome and Firefox browser add-ons and extensions.</quote>
    • Deals
      • Google
      • Some “Alexa top 100″ site, spoken for anonymously by an ex-employee.
  • AdBlock
    • Not Ad Block Plus, but something else
    • Michael Gundlach, founder, ex-Google
  • ClarityRay
    • Ido Yablonka, CEO
    • URL-swapping mechanism
    • Funding: around $0.5M
  • Destructoid
    • Niero Gonzalez
  • Disconnect
    • Casey Oppenheim, co-CEO
  • Evidon
  • Geekzone
    • Mauricio Freitas, publisher
  • Google
    • 2013-03 => removed Ad Block Plus from its Google Play store, 2013-03
    • 2013-06 => deal with Ad Block Plus

      • Media
        • search ads
        • sponsored search results
      • Venue
        • Google
        • AdSense partners
  • Interactive Advertising Bureau (IAB)
    • Mike Zaneis, senior vice president
  • PageFair
    • JavaScript countermeasure
    • Sean Blanchfield, CEO
    • Funding: around $0.5M
  • Reddit
    • Erik Martin, general manager
  • Some Site
    • Not named explicitly
    • “top-ranking in Alexa”
    • Spoken for by an ex-employee.
    • <quote>On the other hand, the former executive at the Alexa top-ranking site said an Adblock Plus representative told him he had to pay even though Adblock Plus agreed that the publisher’s ads were acceptable and should not be blocked. “If we didn’t pay they would continue to block us. To me it seems like extortion,” he says.</quote>

Quoted for color, breadth & verisimilitude


  • Only time will tell (the old saw)
  • <quote>Everything turns on what consumers do next. </quote>

Via: backfill
Via: Soulskill; Ask Slashdot: Are AdBlock’s Days Numbered?; In Slashdot; 2014-01-17.

When cookies go away: Google, ad exchanges, and ISPs fighting to control the future of the Internet | VentureBeat

John Koetsier; When cookies go away: Google, ad exchanges, and ISPs fighting to control the future of the Internet; In VentureBeat; 2013-09-27.


  • Track-n-targ solutions can be implemented at any layer
    1. operating system layer (Google, Apple, Microsoft)
    2. browser layer (Google, Microsoft, Apple, Firefox, Opera)
    3. ISP layer (e.g. Comcast, AT&T, any telecom)
    4. application layers
      1. social layer (Facebook, Twitter, Google)
      2. search layer (Google, Microsoft, Yahoo!)
      3. ad exchange layer (DoubleClick, Google, Facebook, Microsoft, Right Media, Quantcast, etc.)


Gratuitously and to set the mood …

Via: backfill

Why Mobile Web Apps are Slow | Drew Crawford



He puts the abstract-summary at the end.


  • Javascript is too slow for mobile app use in 2013 (e.g., for photo editing etc.).  
    • It’s slower than native code by about 5
    • It’s comparable to IE8
    • It’s slower than x86 C/C++ by about 50
    • It’s slower than server-side Java/Ruby/Python/C# by a factor of about 10 if your program fits in 35MB, and it degrades exponentially from there
  • The most viable path for it to get faster is by pushing the hardware to desktop-level performance.  This might be viable long-term, but it’s looking like a pretty long wait.
  • The language itself doesn’t seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code
  • Garbage collection is exponentially bad in a memory-constrained environment.  It is way, way worse than it is in desktop-class or server-class environments.
  • Every competent mobile developer, whether they use a GCed environment or not, spends a great deal of time thinking about the memory performance of the target device
  • JavaScript, as it currently exists, is fundamentally opposed to even allowing developers to think about the memory performance of the target device
  • If they did change their minds and allowed developers to think about memory, experience suggests this is a technically hard problem.
  • asm.js show some promise, but even if they win you will be using C/C++ or similar “backwards” language as a frontend, rather than something dynamic like JavaScript



By section

The genre of “Which is better: native or HTML5″ “Who will win?”

Three criticisms about benchmarks

  1. Whether JIT is appreciably slower where it matters (benchmarks do not matter).
  2. JIT gets better every day, native does not; oOne day soon, JIT will be “faster than native.”
  3. Python, PHP, Ruby (fully-interpreted code) is already fast enough for ultra-high scale, this is single-user, so what’s the point?

Performance Baseline & Benchmarks

Performance Evolution and Possibilities

Language Tradeoffs: Native vs Managed

Managed languages optimize for developer productivity with JIT thrown in to recover some of the drain.  Native languages don’t have that overhead.  Even the proponents admit this. In archaeological order, not article order:

On Garbage Collection contra Explicit Memory Management

Screen Shot 2013-05-14 at 10.15.29 PM

Hertz, Berger; Quantifying the Performance of Garbage Collection vs Explicit Memory Management

Claim: Garbage Collectors need 6x (4x) more memory than “is necessary” in order to be efficient enough for real-time UX-type applications.  See the chart where the relative memory footprint approaches 1x; consider that 1.5x to 2x is “acceptable performance degadation.”

How Much Memory is Available on iOS?

  • iOSMemoryBudgetTest by Jan Ilavsky
  • Observed limits in the field, on his gear
    • iPhone 4S
      • warn => 40MB (around)
      • killed => 213MB (around)
    • iPad 3
      • warned => 400MB (around)
      • killed => 550MB (around)
  • Walk the scenarios against the limits
  • Multiple copies of the same photo in memory
    Citing also the slide from Session 242, iOS App Performance – Memory, 2012

    1. The camera screen that shows you what the camera sees,
    2. the photo that the camera actually took,
    3. the buffer that you’re trying to fill with compressed JPEG data to write to disk,
    4. the version of the photo that you’re preparing for display in the next screen
    5. the version of the photo that you’re uploading to some server,
    6. the buffer that is going to hold a smaller photo suitable for display in the next screen,
    7. the buffer that resizes the photo in the background because it is too slow to do it in the foreground.</quote>
  • Multiple copies of the same video frame in memory
    Citing also Technical Q&A QA1708 Improving Image Drawing Performance on iOS

    • Q: What can I do to improve my image drawing performance (CGContextDrawImage, UIImage/-drawInRect:, etc)?
    • “Every UIView is backed with a CALayer and images as layer contents remain in memory as long as the CALayer stays in the hierarchy.”
  • Compare the iPad 3 display with a pure display
    (though these are larger, brighter, faster, etc.)

Packaging of ARM Technology

Addressing the need/ability to add more memory to ARM PoP in order to make garbage collection performant; i.e. can one get 6x more memory on some future hypothetical ARM PoP in order to make GC be performant enough to use?

In archaeological order

On JavaScript and Garbage Collection


  • Benchmarks
  • Hardware
    • Intel x86
    • ARM
  • Native (C, Objective-C, C++)
    • GCC
    • LLVM
    • ICC (Intel-closed-secret-proprietary)
  • Java
    • There is only One. True. Compiler. here, right?
  • JavaScript
    • V8 of Google
    • Nitro JS
    • Nitro/SFX
    • TraceMonkey/IonMonkey
    • Chakra,
    • ASM.js
  • Lua
    • A simpler language with a simpler interpreter, via Brendan Eich
  • Period Pieces
    • Internet Explorer 8 (veeerrrryyyy sllllooowwwww)
    • Firefox 3.0.3, when Firefox becomes “fast”
      • Firefox 19 (Firefox 22), current
    • Chome 8, when Chrome became “fast”
      • Chrome 26, current




Apple Developer Documentation


  • Andreas Gal’s dissertation



Pithy, trenchant, money (quote), etc.
Unless otherwise stated, from: Why mobile web apps are slow; In His Blog; 2013-07-09.

  • <quote>The thing is, JITing JavaScript was a 60-year old idea with 60 years of research, and literally thousands of implementations for every conceivable programming language demonstrating that it was a good idea.  But now that we’ve done it, we’ve run out of 60-year-old ideas.  That’s all, folks.  Show’s over.  Maybe we can grow another good idea in the next 60 years.</quote>

Ahem …


  • <quote>The ground truth is that in a memory constrained environment garbage collection performance degrades exponentially.  If you write Python or Ruby or JS that runs on desktop computers, it’s possible that your entire experience is in the right hand of the chart, and you can go your whole life without ever experiencing a slow garbage collector.  Spend some time on the left side of the chart and see what the rest of us deal with.</quote>
  • <quote>With garbage collection, the winning move is not to play.  A weaker form of this “the winning move is not to play” philosophy is embedded in the official Android documentation:

    Object creation is never free. A generational garbage collector with per-thread allocation pools for temporary objects can make allocation cheaper, but allocating memory is always more expensive than not allocating memory. As you allocate more objects in your app, you will force a periodic garbage collection, creating little “hiccups” in the user experience. The concurrent garbage collector introduced in Android 2.3 helps, but unnecessary work should always be avoided. Thus, you should avoid creating object instances you don’t need to… Generally speaking, avoid creating short-term temporary objects if you can. Fewer objects created mean less-frequent garbage collection, which has a direct impact on user experience.


  • <quote>I can give you three frames of reference that are both useful and approximately correct.
    • If you are a web developer, think about the iPhone 4S Nitro as IE8, as it benchmarks in the same class.  That gets you in the correct frame of mind to write code for it.  JS should be used very sparingly, or you will face numerous platform-specific hacks to make it perform.  Some apps will just not be cost-effective to write for it, even though it’s a popular browser.
    • If you are an x86 C/C++ developer, think about the iPhone 4S web development as a C environment that runs at 1/50th the speed of its desktop counterpart.  Per the benchmarks, you incur a 10x performance penalty for being ARM, and another 5x performance penalty for being JavaScript. Now weigh the pros and cons of working in a non-JavaScript environment that is merely 10x slower than the desktop.
    • If you are a Java, Ruby, Python, C# developer, think about iPhone 4S web development in the following way.  It’s a computer that runs 10x slower than you expect (since ARM) and performance degrades exponentially if your memory usage goes above 35MB at any point, because that is how garbage collectors behave on the platform.  Also, you get killed if at any point you allocate 213MB.  And nobody will give you any information about this at runtime “by design”.  Oh, and people keep asking you to write high-memory photo-processing and video applications in this environment.


  • <quote>The desktop market is shrinking year-on-year.    Computers are going to be what the hardcore professionals use–Photoshop  and Visual Studio will always stick around–but mere mortals who spend all day in Excel or Outlook or Powerpoint are going to migrate to ARM tablets.  (Maybe even ARM notebooks.)  Some of us like desktop computers for ideological reasons, or like x86 on the technical merits, or whatever.  But the truth on the ground is that ARM is rising and x86 is falling, like it or not.  Even if we throw out all the smartphones and tablets, you have reasonable research firms projecting things like a 60-40 ARM-Intel netbook split for 2013. And once you throw the tablets and smartphones back in, well, let’s just say that more ARM chips were fabbed last yearthan all the x86 chips ever made.  The sky is falling.  The building is on fire.Whenever you make a platform decision, you’re making a bet.  If you’re writing a web app, you’re essentially betting either 1) that ARM doesn’t matter, 2) that ARM customers will just suck it up and use your slow product,  3) that the web browser guys will wave a wand and make it faster, or 4) that the WiFi guys will fix the speed of light so that everybody has a zero-latency always-on connection to an x86 chip.  Unless you’re writing Photoshop, or writing an app with two buttons, I think you’re nuts.</quote>
    From: Mobile web apps are slow; In His Blog; 2013-05-06.


Humorous, ironic or off-the-cuff

Via: backfill