Tuesday, June 25, 2013

22.0 is finally available (downloads, release notes). The biggest change you will notice is that Growl notifications are now replaced by XUL notifications, and that there is now a download progress bar for the Dock icon (courtesy vasi, who I know floats around this blog periodically). There are also CSS3 and HTML5 advancements, and evolutionary improvements to how images are managed and rendered.

In 22.0 Mozilla also announced official support for teleconferencing through WebRTC. We should, at least in theory, be able to support this given a fast enough Mac. It may well be hopeless for almost all G3s, but I should think voice-only comms should work for most G4s, and the high end G5s might even be able to do video. I don't really want to announce WebRTC support until it's been tested, though, and my unusual network setup may be interfering with testing. I'd like to see how others do with the WebRTC demo -- go to the apprtc. link at the top and it will provide a connect URL for another user to connect to. Oddly, on my network, it simply connected to itself, but I have a rather unfriendly firewall and I suspect it is interfering with the peer-to-peer communication protocol. That said, my antisocial chat with myself in full video and audio proceeded at nearly full speed on this quad. Please post your testing results in the comments. If it appears to work well, then it will be officially supported in whatever the next stable branch happens to be.

I'm removing all the methodjit stuff from the changesets, and then it will be BaselineCompiler or bust after that. Do not expect a 24 aurora any time soon. If there are high or critical severity security issues repaired in 23, I will issue a 22.0.1 interim release with those issues if 24 is not ready for testing. Remember, 24's JavaScript performance will be worse. The idea is to hopefully get away with it.

Thursday, June 20, 2013

Bryan Berg on ADN identified that LinkedIn got DNS-hijacked for about an hour or so yesterday before it was noticed and corrected. This is already a bad thing, because by hijacking the linkedin.com domain name it could be redirected to any site, including ones that might host malware or drive-by downloads. These are low risk to us PowerPC holdouts, but it gets worse: some of you who use LinkedIn regularly should also realize that your long-lived LinkedIn login session credentials may have been transmitted without encryption to the malicious site that temporarily took over the domain name. If you use LinkedIn and saw the malicious redirect (a link farm or some such called Confluence Networks), they got leaked. Even if Confluence didn't themselves collect them, a snooper in the middle may have. This might be a good time to change your password, even if you didn't (or didn't think you did) access LinkedIn during the vulnerable timeframe.

There is an extension called HTTP Strict Transport Security (HSTS) that is supposed to minimize the potential attack window for these kinds of situations -- the browser has a built-in whitelist of sites, which can be added to as the browser receives certain headers from the server, saying they can only be accessed with encryption over SSL. Naturally LinkedIn did not implement this, and that unacceptable oversight is all on them. But if they had, because the Confluence redirect was not encrypted, the browser, seeing that SSL was not available on the malicious server, would have stopped immediately and not transmitted the login credentials or visited the page. Even if Confluence had implemented SSL, they would not have been able to generate a trusted certificate matching the domain name, assuming the certificate authority wasn't incompetent, and self-signed certificates that have not already been approved by the client fail HSTS.

This is another potential issue with older browser security on Power Macs. Chrome, Opera and Firefox support HSTS, but HSTS wasn't added to Firefox until 4.0 (meaning not until TenFourFox) and the default whitelist wasn't implemented until 17, and not to Opera until version 12. Safari has never supported it, nor iCab, nor Camino, nor Roccat, nor OmniWeb. Yes, not all sites support it that should, but it's easy to add, and it's a security measure that could have prevented this leak. If LinkedIn had implemented this correctly, TenFourFox users would not have been vulnerable, and TenFourFox users are not vulnerable to similar attacks on sites that are HSTS-protected.

17.0.7 is building remotely as we speak on my G5 and I will be back at my desk tomorrow fully rested from my lovely vacation. There was a late breaking issue with 22's updater support, so unstable branch may get delayed until Sunday or Monday, but 17.0.7 should be up by tomorrow PM with the usual security and stability updates and a definitive fix for issue 225. It will finalize on Monday PM as usual. After that begins the death march to 24 and BaselineCompiler or bust.

Saturday, June 15, 2013

I am in British Columbia today, where the Dr Pepper has real sugar, not high fructose corn syrup (non-US readers: the bizarre sugar tariff situation in the USA means that HFCS-42/HFCS-55 is cheaper to use in most applications where sugar/sucrose would be, particularly in soft drinks, and IMHO there is a non-trivial taste difference). It is the closest thing left commercially available that in any way approaches the nirvana that was Dublin Dr Pepper (r.i.p.), so if you hear about someone busted for smuggling several cases of Dr Pepper into Washington state, that was me and please bail me out. Between Mexican Coke and Canadian Dr Pepper, I think Mr Pibb -- in the form of the inferior but still delightful Pibb Xtra -- is the only domestic beverage I still drink regularly.

While prepping patches in my hotel room to attack the summit that is Firefox 24 (I am gradually eliminating the "not implemented yet" stubs in my internal IonMonkey build, though I still can't test Baseline Compiler yet), I am purging old code from our changesets that no longer holds relevance. Most of this is for methodjit/JaegerMonkey, which of course no longer exists, but during the debugging of the Type 1 bitmap font issue definitively fixed in TenFourFox 17 I added the tenfourfox.gfx.badfont.* prefs to allow people to force fallbacks in place of Arial, Helvetica and Times if those fonts actually were Type 1 bitmaps which HarfBuzz, TenFourFox's sole font renderer, can't process. This should not be necessary anymore since TenFourFox will automatically filter such fonts now and I'd like to remove the prefs to eliminate the amount of code that needs to be merged. If someone absolutely still must use these prefs to render web pages, I would like to find a better solution for you, so please advise. They will be left in 17 through the end of 17ESR and will make their last appearance in the unstable branch 22, to be removed in 24ESR.

So, since I'm on vacation, I wanted to remind you of some possibilities Apple has for future versions of OS X after places in California that have inspired me:

OS X Fresno

OS X Bakersfield

OS X Clapper Gap (thanks Bill Childers on ADN)

OS X Brawley

OS X El Centro

OS X Wasco

OS X Pumpkin Center (Kern county is just a gold mine for fun place names)

OS X Barrio Logan

OS X Rio Linda

OS X Compton (requires optional Thunderbolt Glock .40)

OS X South Central Los Angeles

and, of course, something that I know inspires Apple a lot,

OS X Weed

Jason Rehmus on ADN also proposed OS XXVIIII Palms for the next version. Makes perfect sense.

To make this blog post actually have a point, though, this presents any app that supports versions prior to 10.9 (and most will, though 10.9 appears not to drop support for any 10.8-compatible machines) with a problem: the new flat visual style in 10.9 is rather different from 10.8 and before, which itself is rather different from 10.6 and before. I expect to see a new skin appearing in Firefox to make this work correctly, which should be rather unfun given that they've only just gotten the 10.7-era scroll bars to behave like the rest of the operating system. It also further complicates our own support, though I have always planned to break apart our widget support and maintain it independently, probably after 10.6 support is dropped sometime between Fx24 and Fx31. We'll just have to see what happens.

By the way, I already have an iBook that works with Mac OS X. Oh, that's not the same thing?

Monday, June 3, 2013

For some time we've been watching Australis, the new Firefox tabs and browser interface. Although the user interface in Firefox and TenFourFox is based on XUL, which is ostensibly cross-platform, it is specific to each of the supported tier-1 platforms and has hooks in it for system-dependent features so that the skin on the Mac app acts more like a Cocoa application than, say, Windows. (How successful this approach is, of course, lies entirely in the eye of the behoulder.) Now that Mozilla has dropped both 10.4 and 10.5, we need to watch what system requirements become enforced for UI platform support because that can break us badly, and Australis is a big change.

Right now and for the many months it has been in gestation, Australis has been mostly confined to the UX branch, which we neither support nor build from. Although some platform prerequisites have been implemented in the main browser, and coded around if needed in our case, the browser still looks and acts pretty much the same as it did going all the way back to Firefox 4. But that's about to change: Mozilla is announcing Australis will land probably in the Fx25 timeframe, and if not fully activated then, it will be shortly afterwards.

Let me say this now: I am not impressed with Australis. I think it is an inefficient use of screen real estate, particularly since it wastes space on screens like ours which may not be especially wide with its swooping rounded tabs, and the borders seem abnormally fat. It has some known performance concerns, though in fairness these are being worked on, and the whole thing smacks of "out-Chroming Chrome" because Australis looks an awful lot like a Chrome knockoff. That said, I will still try to support it regardless because we do want to maintain source parity as long as possible, and if it can be made to work technically, it will also maintain our add-on and theme compatibility (and anyway you can bet that someone will create a theme to restore the old tab appearance as soon as this hits the release channel).

Australis is not going to land until after the ESR24 branch, so I'm not going to worry about it now; we're going to deal with it for the unstable releases after that. If Australis cannot be made to work on 10.4/10.5, then we will transplant the old skin over and try to get by with the previous interface for as long as possible, but this will impair add-on compatibility and may make the browser interface buggy. I am, however, cautiously optimistic that based on the underlying system work I've seen land thus far, for better or worse Australis can be ported to 10.4. I think that supporting it is the best long term approach from a technical and maintenance perspective, even though I, for one, do not welcome our new rounded tab overlords.

The IonMonkey work continues; BaselineCompiler is about 50% done, and I am filling in the gaps in the trampoline and the new assembler as I discover them. I am still not able to test anything, but at least it still compiles.