Showing posts with label mobile web. Show all posts
Showing posts with label mobile web. Show all posts

Thursday, January 21, 2016

Can't see Instagram in Firefox?

Trouble was, that Instagram and embedded Instagram pictures recently stopped loading in Firefox.
This also affects other Gecko-based browsers.
> If you want to skip the story, jump to solution.

While I also use NoScript on desktop Firefox, and on Firefox for Android, all the necessary instagram domains were allowed.

On the desktop, I'm mostly using Firefox 39.0.3, because it plays well with Flash. (There were no issues like that with other browsers.) First I thought, that this was because I wasn't using the latest Firefox. As this Firefox version plays well with Flash, I didn't want to upgrade to the latest version, because with the latest Firefox, Flash playback on YouTube is jerky since Firefox 40.

But the Instagram issue repeated, when I was also using the latest Firefox for Android. Initially I thought, that this was the fault of Instagram, and since I don't use Instagram or Facebook, I didn't think much beyond that. And for a month or so, I couln't resolve it.

But when Instagram showed in a different computer in the latest desktop Firefox (43.0.4) with the same extensions installed, I began to investigate again.

When reloading a random Instagram page while also watching the Firefox Browser Console, I found an error, which, in pasted form, looks like this:
05:16:59.308 An error occurred during a connection to instagramstatic-a.akamaihd.net:443.

Peer attempted old style (potentially vulnerable) handshake.

(Error code: ssl_error_unsafe_negotiation)
1
After some searching, I found the solution in a game forum.

SSL safe negotiation setting

Turned out, that when perusing the Privacy Settings extension of Firefox, I had turned all the settings to most secure, and among them turned on security.ssl.require_safe_negotiation. After I turned that off, Instagram showed again.

If you don't have the Privacy Settings extension installed, go to about:config and type in or paste security.ssl.require_safe_negotiation . The boolean setting value for it should be false. If not (if it's true), then double-click the setting or press enter on it to set it to false. Or right-click for context menu to Toggle.


Otherwise, the Privacy Settings extension is awesome, and I recommend it to everyone.

Whereas people who manage instagramstatic-a.akamaihd.net, should implement new-style SSL/TLS handshakes to keep their corner of the web safe.

So this was the issue that affected me.

NoScript

If, on the other hand, the above is not an issue, then you might be having NoScript installed to defend your browser from malware, and among other things, it's blocking Instagram domains, which means they're not in the whitelist. Jump to domains.

NoScript has a blue "S" button that shows the status of whether a page is completely blocked, half-blocked (content from other domains has been blocked, which is most common), or completely allowed.

That button is usually visible in the location bar, or accessible through Firefox's hamburger menu. (If the blue 'S' is not there either, click the green Customize button in the hamburger menu to see if the NoScript button is listed in the 'Additional Tools and Features' section.)

One can change NoScript domain permissions thus:
* Hover the pointer over the blue "S" button, which launches a menu with a list of domains. If the NoScript menu is very long, it has small up and down arrows for scrolling.
* To whitelist a domain, click on "Allow domainname.tld". Alternately, domains can be blocked by clicking on "Block domainname.tld". This can be done in one go for several domains.
* Once the cursor hovers away from the menu, NoScript will automatically reload the affected page (or pages in other tabs). If a page or pages don't reload (per custom settings), they can be reloaded manually.

For Instagram, the following domain names must be allowed:
platform.instagram.com
instagramstatic-a.akamaihd.net
www.instagram.com
The above are all third-level domains, because they contain three name components separated by periods/dots.

By default, NoScript shows only base second-level domains, such as instagram.com without the www and a dot. For most common users with NoScript, allowing instagram.com and akamaihd.net is sufficient.

Monday, July 28, 2014

Performance optimization of mobile sites

This is in reaction to a post on Google Plus complaining about why the BBC mobile site wouldn't serve large images to a phone that is capable of downloading and displaying them. (This is current practice on many mobile sites, as it were.)

So, the BBC website is also serving developing countries, where the best mobile infrastructure consists of what in advanced economies is essentially legacy technology. For example, only this year did Pakistan begin adopting 3G.

Many sites are not necessarily willing to incur additional bandwidth costs, unless they were ready, willing, and capable of serving very large amounts of content (such as YouTube).

Another typical issue is with designers of lesser websites, who fail to optimize their content.

Mobile data connections incur charges for data, which can be substantial for people with limited budgets. Thus a major factor to consider when designing a mobile site with worldwide viewership is responsible data usage, which then requires designs that are made for the lowest common denominator.

Because when people must pay money to read a website, they will avoid those that are expensive to visit.

AFAIK, there seems to be no easy way for a site to automatically detect if a user is visiting through 2.75G (GRPS/EDGE), 3G or 4G. The best indicator is the user agent string, but that doesn't always tell if the phone is actually on the net via 3G/4G; only that the device is capable of such.

If phones were able to report through the user agent string that they're browsing via 3G/4G, or even better — if a device were able to report its download speed on a certain network/infrastructure, websites would be able to fine-tune the content served to their various visitors. Unfortunately, this would be ripe for abuse, if content providers began actively excluding devices with speeds and connections under a certain threshold.

Another point to consider is that when mobile phone users are tied to a limited data plan, they are not willing to download more than absolutely necessary. This being text, and more would be large images.

A solution could be for mobile users to select which connections they would want which version of site. If people have a limited plan, they'd want small content; if using a dedicated connection over Wi-Fi, they'd be content with bigger images.

There are some solutions (or workarounds), such as one based on cooperation between site and user by implementing cookies to select the lite or heavy site, if such functionality is offered. There are also apps for mobile devices.

Another possibility is for users themselves to specify which version of a site they want to visit at a time, especially if a mobile version is on offer.