If you’re still using UsableNet or NetBiscuits, you’re fucked

Starting about now, after a period of testing, Google is switching over to a mobile-first search index. This means that search results will be based on the content seen on the mobile version of your website even if there is more content on the desktop version, and depending on how you are supporting mobile browsing, that could be a problem. Continue reading  

Adobe AEM Mobile firewall settings

Are you looking for firewall settings to allow your AEM (AKA CQ5) author server communicate with Adobe servers to enable AEMMobile integration?

To enable AEMMobile to integrate with regular AEM (despite the name, they are two entirely different products, the former being a new version of what used to be called DPS or digital publishing system) requires numerous firewall settings to be enabled on your author server.

Unfortunately none of the setup guides provided by Adobe tell you what those settings are, and due to bad SEO, the page with the settings on is not easy to find, not least because it doesn’t reference AEMMobile, instead using the old DPS designation.

But not to worry! You can find the necessary page here:

https://helpx.adobe.com/digital-publishing-solution/kb/Problems-Accessing-DPS-2015-servers.html and in case that page disappears again next time Adobe , here are all the firewall endpoints to need to open up:


White-list servers that are used for Adobe Experience Manager Mobile functionality

IT departments can white-list the servers involved in providing the Adobe Experience Manager Mobile functionality. Then, communications with the servers are unimpeded and don’t require user authentication. Below are the servers that the Adobe Experience Manager Mobile’s components use.

These domains use dynamic IP address configurations. So white-listing based on IP addresses gained from a DNS query at one point in time is not reliable. IP addresses for these DNS entries are eliminated and added at any time based on Amazon’s Web Services’s (AWS) fail-safe methods, and expandable server capabilities.

Adobe Experience Manager Mobile Portal

Adobe Experience Manager Mobile Portal:

  • http://aemmobile.adobe.com
  • https://aemmobile.adobe.com
  • https://adobedigitalpublishingportal.d1.sc.omtrdc.net
  • https://ps*.pubnub.com (will vary based on load balancing, for example, https://ps14.pubnub.com)
  • https://dpm.demdex.net
  • https://adobe.demdex.net
  • https://wwwimages2.adobe.com
Login/Account Management Service:
  • https://ims-na1.adobelogin.com (identity management service)
  • https://amas.publish.adobe.io (account management and authorization service)
  • https://authorization.publish.adobe.io (authorization service)
Content/Publishing Services:
  • https://pecs.publish.adobe.io (producer service)
  • https://ings.publish.adobe.io (ingestion service)
  • https://ps.publish.adobe.io (product service)
Migration Service:
  • https://migs.publish.adobe.io
  • https://geo*.adobe.com (may vary, for example, https://geo2.adobe.com)
  • https://universal.iperceptions.com
  • https://origin.adobe-dcfs.com
Analytics Service:
  • http://www.adobe.com
  • https://www.adobe.com
  • https://mobilemarketing.adobe.com
  • https://omniture.tt.omtrdc.net
  • https://adobe.tt.omtrdc.net
  • https://my.omniture.com
  • https://www.omniture-static.com
  • https://sc-css-1.omniture.com
  • https://scripts.omniture.com
App Builder Service:
  • https://ab.publish.adobe.io
  • https://dps-ab-prod-s3-service-*.s3.amazonaws.com (will vary, for example, https://dps-ab-prod-s3-service-1xe1vppi79wya.s3.amazonaws.com)
  • https://s3.amazonaws.com
Push Notification Service:
  • https://rps.publish.adobe.io
  • https://fonts.adobe.com
  • https://use.typekit.net
  • https://p.typekit.net
Debug Logging:
  • https://sstats.adobe.com
  • https://universal.iperceptions.com
  • https://helpx.adobe.com (support)
  • https://api.behance.net (Behance integration)
  • https://assets.adobedtm.com
  • https://universal.iperceptions.com
  • https://*.vo.msecnd.net (will vary, for example, https://az452423.vo.msecnd.net)
  • https://*.cloudfront.net (will vary, for example, https://d13itkw33a7sus.cloudfront.net)

Adobe Experience Manager Mobile Apps (Including Adobe Preflight)

  • http://adobepublish*.sc.omtrdc.net (analytics service, will vary based on the data center used by a given application, for example, http://adobepublishdallas1.sc.omtrdc.net)
  • https://edge.publish.adobe.com (source of content downloads)
  • https://mobile-collector.newrelic.com (performance and crash logs)
  • https://es.publish.adobe.com (entitlement service)
  • https://cs.publish.adobe.com (configuration service)
  • https://rps.publish.adobe.io (rich push service)
  • https://logs.aemmobile.adobe.com (debug logging)


Adobe Experience Manager Mobile Web Viewer

  • https://viewer.aemmobile.adobe.com
  • https://edge.publish.adobe.com (content source)
  • https://es.publish.adobe.com (entitlement service)
  • http://adobedigitalpublishingjupiter*.sc.omtrdc.net (analytics service, will vary based on data center location, for example, http://adobedigitalpublishingjupitersanjose.sc.omtrdc.net)

Three wants its fair share of those billions of advertising dollars

And so ad-blocking comes to mobile but not in the form of browser plugins. Three’s decision to trial blocking ads at network carrier level may be said to be all about improving the customer experience, but what’s really in it for Three?

Ostensibly, it’s being positioned as being to the benefit of the consumer, whose data tariffs get eaten up by the advert assets in their 3G and 4G traffic. But while there may be some truth in that, bandwidth is cheap in the year 2016, and customers are increasingly turning to SIM-only deals with more GB included than even the heaviest Netflix user could use.

Now that everyone who wants one has their iPhone or Android equivalent, and more people use WhatsApp than traditional text messages, the real issue is that carriers like Three are faced with the same awful realisation as fixed line ISPs – they may be nothing more than bit pipes, racing each other to zero to see who will stop making profits first.

So what’s a mobile network to do to avoid this fate? Latching on to consumers’ increasing tendency to use ad blocking is not a bad place to start. But not in order to save them money and not to make their internet go faster. Not even to protect their user from adverts that are effectively trojan horses for computer viruses.

Those are simply beneficial side effects, a means to an end that makes the real plan more palatable. There’s an endgame for the likes of Three, which they hope will see them getting what they see as their fair share of all those billions of advertising dollars.

What Three, Digicel and Shine are doing here is introducing a tollgate on ads. At its simplest, this technology can be used to make advertising networks pay a share of their revenue to un-block their ads. We’ve already seen this with Adblock Plus’ Acceptable Ads programme. The spin will be “if you want to use our customers’ valuable bandwidth for ads, you can pay for the bandwidth”.

It sounds almost fair when put like that doesn’t it? As an opening gambit for a negotiation, it’s a bit like Donald Trump proposing to build a wall on the Mexican border. Start with a completely extreme opening offer, with the intention of meeting somewhere closer to the middle where a fairly ridiculous proposition feels acceptable when compared to something outrageous.

That middle ground is where the mobile networks, and other ISPs for home broadband, office networks and even operators of hotel, shopping mall and in-flight Wi-Fi access, have something even more valuable up their sleeves to sweeten the deal for the advertisers.

For all that Google and Facebook and the rest may claim to know about how to target visitors’ real life needs, the reality is that adblocker usage is growing fast, that viewability metrics are a fraud, and click bots are driving nearly half of all ads.

It’s a bit like Donald Trump proposing to build a wall on the Mexican border. Start with a completely extreme opening offer, with the intention of meeting somewhere closer to the middle where a fairly ridiculous proposition feels acceptable when compared to something outrageous.

Even the appearance in Private Eye magazine of a regular Malgorithms column of inappropriately targeted online ads shows how normal it has become to laugh at, not click on, poorly targeted ads.

The advantage they have is internet data has to hop from server to server to reach the end user – but it all has to pass through one particular hop, the last hop, from the mobile network/ISP to the users’ devices. And it so happens that such organisations know who the user truly is, where they live, how much they spend and exactly what they do on the internet all day long.

Unlike Google and Facebook’s best guess tracking data, they know exactly who you are and what you might be interested in.

By leveraging their unique position in the relay of ads to ensure the level of personalisation is sufficiently high that users might be willing to tolerate them once more, they become an essential part of the ad value chain.

Of course, they can’t sell or give that information away, but if the systems that select the relevant ads reside within their own network, such as with AdKlickers‘s patent pending tech, there’s nothing stopping them replacing a default ad unit with a personalised one, and charging the advertiser a premium. Such a trick might even fool adblockers.

So, true ad personalisation? Check. Defeat adblockers? Check. Get someone else to pay your bandwidth costs? Check. The mobile networks might yet avoid their commoditisation fate if they can pull this one off.

This article was originally published on Campaign Live