It's OK for Apple to block Firefox, but wrong when Microsoft does it - <AUTHOR> http://blogs.computerworld.com/20159/mozillas_hypocrisy_its_ok_for_apple_to_block_firefox_but_wrong_when_microsoft_does_it <comment><USER2> A lot of people, including the author of this article, seem to think it's unfair that Mozilla is not giving equal complaint time to both platforms. That's the fundamental issue here.

Maybe, _all things being equal_ , that would be a fair complaint but all things are _not_ equal.

First of all, the limitations of iOS and app store are well known and retread at least once a month on HN since the site opened. Mozilla certainly did complain about iOS _years ago_ and decided ultimately to abandon the platform. We're talking about Windows now because Windows 8 is due to be released.

Secondly, Firefox's primary platform is Windows and they already have working version of Firefox for Windows 8 with a Metro UI for x86. Only a minor technical limitation keeps them from releasing it for ARM -- that's not true of iOS.

Lastly, there is a still a chance Microsoft might cave on this issue. We know from years of experience that Apple won't.

<comment><USER3> Post-lastly: there's the simple point that Firefox for Windows is an actual product that could be shipped near-immediately. There is no Firefix for iOS, precisely because Apple has never allowed it.

I think the broad point is valid though: Apple's platform control is no more morally justified than Microsoft's. And at least in the abstract they deserve equal scorn. But the specifics here are that Windows 8 on ARM won't run an app that can clearly be shipped (and will be for x86). That's a problem with a reasonable hope of being fixed, so it makes practical sense for Mozilla to whine about that first.

Post-post-lastly: it bears mentioning that if Safari was as bad as IE, Apple might draw more fire. It helps a lot to have a browser that doesn't lag the state of the art.

<comment><USER4> What you're missing here is that Apple bans everyone equally while Microsoft does not. What I mean by that is the App Store doesn't discriminate on an individual basis. Apple is generally consistent in their "unfairness". Looking at what Microsoft is doing, their decision to restrict Firefox immediately struck me as an anti-trust monopoly issue. They're not restricting Firefox on the basis of some policy that applies to everyone but singling out one piece of software.

The argument in this article is a red herring. This isn't about fairness. It plays on the whole Apple v. Microsoft thing and tries to drum up sympathy and or guilt by playing the "you're just hating on MS because it's trendy" card in a way. It really looks like Microsoft has decided to restrict Firefox capabilities on ARM devices so their browser can have a leg up and deliberately and negatively impact the user experience of Firefox on certain devices.

Framing this using Apple and it's policies/practices are an attempt at misdirection. If you take this attempt to play the Apple v. Microsoft card out of the equation and for a moment pretend Apple never banned FF and FF never even tried to get on iOS what you're left with is Microsoft unfairly discriminating against one company in an obvious attempt to stamp out any competition. It's a pretty cut and dry case of ant-trust once you weed out all the distractions.

Edit: clarified the first sentence of last paragraph. Added the words "Framing this using".

<comment><USER2> > What you're missing here is that Apple bans everyone equally while Microsoft > does not.

You could not have this more backwards. The fundamental issue that Metro apps cannot write to executable memory pages. This is a fundamental security feature of both WinRT and of iOS. Browsers download code off the Internet JIT compile it to native code and execute it. This is what Firefox needs to do. It's not like Windows 8 is checking for Firefox.exe and refusing to load it.

What Mozilla wants is an exception to the normal rules for applications on ARM Windows 8.

Microsoft makes exceptions for their own applications (Office and IE) but that's it. These are the same sort of exceptions Apple make for their apps on iOS.

<comment><USER5> >What Mozilla wants is an exception to the normal rules for applications on ARM Windows 8.

i think where the frustration is coming from is that windows gave them exactly that exception on x86 windows 8. they created a special class of applications for third party browsers, that can run JIT'd and native code in metro mode. now, with ARM, they've decided to revoke that exception for no apparent reason other than "because we can", and it seems more than a little unfair.

<comment><USER2> It's not quite the same because Windows 8 x86 already lets you run every kind of Win32 application that has ever existed. The door is already wide open. Allowing Firefox to run in Metro mode with more compatibilities than the average Metro app actually changes very little.

It certainly more complicated than "because we can".

</comment></comment></comment></comment></comment></comment><comment><USER6> (Disclaimers: I work for Mozilla)

There is a huge difference between iOS and other platforms.

Apple, in legal terms, makes Firefox on iOS impossible. This was not the case with Windows; Microsoft was using covert means to undermine user choice.

To make a blanket statement that Mozilla thinks Apple's banning Firefox from iPad and the iPhone is 'not a problem' is wrong and disingenuous.

We have active projects around ways to give users choice within the constraints of Apple's licensing.

Mozilla fought and won against Microsoft's anti-competitive efforts, under an entirely different technical and legal landscape.

As a Mozillian, I'm pissed and have been pissed off since iOS's launch, but we also have to choose our battles on where we can fight to keep the web open.

To apple's credit, they've provided a web standards based browser to a mobile landscape that didn't have one (at the time) and which spawned many other web standards based browsers like Chrome.

Do I wish Safari on iOS have a freaking file input so I could upload photos from the gallery? YES! Would I want a Firefox browser that was proxy based to get around iOS licensing.... hell no. Is it worth the Mozilla community's time maintaining an iOS based port just for the people who jailbreak their iOS devices... probably not, but no one from Mozilla would stop you from doing the work.

<comment><USER7> > To apple's credit, they've provided a web standards based browser to a > mobile landscape that didn't have one (at the time) and which spawned many > other web standards based browsers like Chrome.

As I recall it, Nokia started using WebKit on Symbian before the iPhone came out.

<comment><USER8> Apple forked KHTML to create WebKit. They kept it open source though and now lots of companies (Nokia, Google, etc.) contribute to it.

</comment></comment></comment><comment><USER9> My feeling here (ex-MSFT employee, so maybe biased one way or another) is that Mozilla is going after the soft underbelly of Microsoft, because they _can_.

Mozilla is already locked out of iOS and they have failed at getting Apple to budge. If WinRT locks them out, they'll be locked out of two out of the three major tablet platforms (it's a safe assumption that WinRT will get some marketshare at least).

Microsoft is an easier target than AAPL - Win8 is still under development so it's still early days and the company has a history with various governmental organizations (the DoJ, the EU). My guess is Mozilla is attempting to rattle Microsoft into opening up Win8 to get Firefox to run. Or drum up enough press, get the DoJ to make a quote or two and really get Redmond to worry.

If I were Microsoft, I would hold my ground. Strategically, it makes a lot of sense to own the browsing experience e2e and I think Mozilla's case is weak given MSFT's lack of marketshare, the existence of Chromebooks, Boot2Gecko, etc.

<comment><USER10> "Strategically, it makes a lot of sense to own the browsing experience e2e"

Can you expand on this?

There are a couple of benefits I can think of, but no major ones. \- Quality of experience: owning the browser ensures that sub-par browsers don't degrade the overall experience (such as destroy battery life and overall platform impressions). \- Controlling innovation: If Microsoft feels threatened by HTML then it can limit certain features until native apps catch up. I believe that this is a double-edged sword though, as Chrome and Firefox steadily push forward people are stil unsure if IE can keep up.

Allowing third-party browsers ensures that your platform always has the best browser and the browser is an incredibly important part of the platform.

Personally, I see not allowing alternate browsers as an attack on the browser ecosystem at a time when Microsoft has been trying to be very standards friendly with IE10. For tablets, I use the browser a _ton_ , and being allowed to run the latest and greatest browser of my choice, with WebGL, Web Intents, etc, and not be tied to IE or Safari, is a selling point.

The cynicist in me says that Mozilla's Boot 2 Gecko Phone project most likely will not support other browsers, and Chrome OS doesn't either, so why should Win8. And I think this really sucks.

<comment><USER9> I don't think Microsoft will make the mistake of falling behind on the web platform again. In fact, their latest moves (both tech, organization-wise) show them throwing more weight behind IE/HTML and less behind .NET/SL/Win32 (this is from me reading the tea leaves from the outside, not any inside scoops).

<comment><USER10> I'd argue that MS is still falling behind- IE10 is just catching up but has no leapfrogging and how far out is IE11?

Even more critically, look at all of the users MS is leaving behind- no XP support for IE9, will they abandon Win8 users when there's still a massive number of them?

Unless IE ramps up their release cycle I see no way they can stay on the leading edge.

</comment></comment></comment></comment><comment><USER11> This is a bit silly. So the point of this article is that Mozilla "should be criticizing Apple?" Why waste a whole article saying someone else should criticize Apple? It seems more worthwhile to do it oneself.

The trouble with trying to dismiss an argument with accusations of hypocrisy is that hypocrites can be _right_. If I make an argument that stealing is wrong and then turn around and steal something, that doesn't mean that stealing is morally permissible. Likewise, the fact that Mozilla neglects to criticize Apple doesn't mean their criticism of Microsoft is incorrect.

<comment><USER12> > Likewise, the fact that Mozilla neglects to criticize Apple

Good points, and furthermore that bit isn't even accurate. Mozilla has been critical of Apple too. But Windows RT is a new product, so there is new cricitism; the criticism of Apple is old.

<comment><USER13> WinRT is not a new product - it's a new API sitting on top of mostly the same Windows kernel they use for Windows 7.

<comment><USER14> Windows RT = New product meant for ARM devices (the current topic of discussion)

WinRT = New runtime API for Metro apps that will run on both Windows 8 and Windows RT.

<comment><USER13> So, it's as much a new product as were Silverlight, WPF and .NET - all layers that allowed apps written for them to run on Windows-based devices.

The kernel underneath is the same.

</comment></comment></comment></comment></comment><comment><USER15> I wonder how many people throwing opinions around this were "of age" in the early-to-mid 90s and thus remember what an unstoppable behemoth Microsoft was.

This was a time when they had 95%+ of the desktop OS share and you basically couldn't run a home computer with Windows. This was the early days of Linux (IIRC in ~1994 I downloaded SLS running Linux 0.99.x onto ~30 floppy drives over a 2400 baud modem!). Macs were an expensive niche product. Personal computing just wasn't possible without Microsoft.

Microsoft very much used this position to kill Netscape as they saw the Internet as an existential threat (fearing Netscape would be the new OS). They tried to subvert Java (the threat of "write once run anywhere" being a threat to the Windows lock-in) and partially succeeded. It was at this time that the DoJ stepped in.

I can't overemphasize the perception the tech community had of Microsoft then. Windows was rapidly evolving. Windows 95 was, I believe, a major turning point for the company (and where it achieved at least technical superiority over MacOS having preemptive multitasking and dynamic memory management). Microsoft really had an aura of _invincibility_.

We are not in this situation today. Apple seems unable to do no wrong (in the marketplace; there are what are still fringe elements criticizing them for any number of things) but don't have the market position Microsoft did.

In fact, Microsoft doesn't have the position Microsoft did in the 90s. At this point I believe we have viable alternatives to personal computing between mobile devices, Macs (you can get a Mac Mini for $600), netbooks and--dare I say it--even Chromebooks (you'll note that I left Linux off that list as I believe it will never be a viable mainstream desktop OS and of course I know it powers Android/ChromeOS).

I certainly don't see an issue (yet) with Apple blocking alternative browsers. Don't like it? Buy an Android. Or a Windows Phone 7. Or a Blackberry (OK, I couldn't keep a straight face with that last one).

Windows and Office are the geese that lay the golden eggs in Microsoft. Everything is beholden to them. As an organization, Microsoft seems terrified they'll die and as we've seen time and time again it's that fear and that switch from innovation to defending your turf that ultimately leads to the death of companies.

I believe the whole Metro API browser thing is just more evidence of Microsoft's stagnation. Let them I say. It'll probably, at least in some small way, hasten either their demise or them attempting to turn the boat around before they go off the cliff.

EDIT: yes Netscape was complicit in its own destruction. I used Netscape up until version 3. By Netscape 4 on a 486DX4/100 at least, IE4 was _significantly_ better and faster and I never switched back (not until Firefox 1.5/2 years later).

Netscape eroded at both ends (IMHO). At one end obviously was Microsoft giving away the equivalent to their consumer product for free (as well as bundling it with the OS, making it harder to use non-IE browsers and so on). At the other end was actually Apache. The Apache Webserver I believe it incredibly difficult to build their server software platform (anyone else remember Netscape's Web servers?).

It wasn't until the rise of search engine advertising some years later that Microsoft's hold could be broken, it being the only thing that makes Firefox and Chrome possible.

As an aside to all those who are anti-ads: how exactly would non-OS browsers exist without advertising?

<comment><USER16> I was around during the time period you're talking about and in my personal experience, Microsoft had plenty of help in killing Netscape from Netscape itself.

I switched to MSIE3 not because of bundling or FUD but because it was a much better browser.

Microsoft has been a bad actor at times when it comes to business practices, but I think a lot of people overestimate how much that helped them and underestimate how much competitor mistakes helped them. Netscape Navigator post-2.0 was a piece of garbage until Firefox rolled around.

<comment><USER17> Quite true, Netscape's rewrite was a pretty bad mistake and when it was actually released it was still bad.

Must read articles by Joel about it.

<http://www.joelonsoftware.com/articles/fog0000000069.html>

<http://www.joelonsoftware.com/articles/fog0000000027.html>

<comment><USER18> Brendan Eich has a different take than Joel: <http://techluminaries.com/2008/12/15/episode-1-brendan-eich/>

<comment><USER19> Is there a transcription available? I can't listen to podcasts at work (and don't listen to them in my free time as a personal preference).

</comment></comment></comment></comment></comment><comment><USER20> I'm going to put this question out here for everyone who's had some experience building a JIT engine of some kind: what exactly is the danger of compiling code, even unknown code like from downloaded javascript, when the process' operating environment is supposed to be hardened anyways?

Is it just that the only way to do this is with VirtualAlloc()/mmap()? Could a 'safe' executable page allocator be created for just this purpose?

If the JIT'ing code is tricked into compiling and executing 'malicious' code, hasn't the operating environment - what libs the process can load, what syscalls it has access to, etc - already been security-hardened? My understanding of WinRT is that it's already a bit of a sand-boxed environment, with limited and measured access to the machine's resources.

If it's possible for the JIT'ed code to do something REALLY bad, like install a driver or write to arbitrary system files or something, then it was possible for the JIT'ing code to do that too, and that's almost certainly a really really bad thing.

Even if it's just a matter of the JIT'ed code violating the trust agreement between the user and the JIT'ing code (ie doing something that the user was OK with Firefox doing, like reading the address book, but doing it for malicious reasons), maybe a new trust agreement can be designed, that would make users aware that the JIT'ing program is inherently a bit more dangerous?

Or maybe what really needs to happen is we have to treat JIT's as pluggable, upgradable OS infrastructure, sort of like the image loader or dyld/ld- linux.so? In that case, if the Firefox would install a browser and the Firefox JIT'ter as separate components, and then Firefox would ask it's JIT'er to compile/execute javascript into a separate process - one with much more limited access to the machine?

<comment><USER21> First three rules of security: Layers, _Layers_ , _LAYERS_.

To your point, _in theory_ you could accomplish security by totally securing the JIT, or by totally securing the OS, and then exec's JITed code would be ok. However, totally secured JITers and OSs are as mythical as sufficiently smart compilers.

<comment><USER22> Totally secure, sure. Nothing nontrivial is totally secure, but...

One reasonable option would be requiring any JIT to be via a typed assembly language. You should be able to get a good compromise with close to the performance of native code and the security of verified bytecode from that.

<comment><USER23> Well, then you have to carefully vet every JITting assembly language. Microsoft in fact does this: the WinRT APIs run on .NET, which has an associated assembly language CIL (formerly MSIL) and JITting runtime, the CLR.

So, if you want a JIT via a typed assembly language you can compile down to CIL. Firefox could do this, but then they couldn't specialize their JIT to run JavaScript properly, which is the hard part anyways. V8 and Gecko are very cool engines, and compiling javascript to CIL wouldn't compete.

</comment></comment></comment></comment><comment><USER24> This seems like a bad move for Microsoft. Few people see them as the horrible monopolistic evil empire anymore, but it's not so long ago that people saw them that way. They got in significant legal trouble just for _bundling_ a browser with Windows. Blocking alternative browsers, or subjecting them to restrictions MS considers too crippling for their own browser seems like a good way to scare off developers and users alike.

<comment><USER13> Scaring users off is not that big a problem for them. Microsoft has 5 vital clients - HP, Dell, Acer, Lenovo and Toshiba. As long as you buy a computer with Windows installed (and it's hard not to) they're happy.

<comment><USER24> Yes, but those clients are expanding their non-Windows offerings. The version of Windows in question isn't for traditional PCs but for ARM tablets. There, it has to compete with Android[1], which has a bit of a head start.

[1] And iOS, when in comes to consumer market share, but that's obviously not an option for the manufacturers MS sells to.

<comment><USER13> > There, it has to compete with Android[1], which has a bit of a head start.

This matters little if MS is able to leverage their power with PC (by modulating the Windows OEM license price) and phone (modulating their Android patent tax) makers to convince them they should build Win8 tablets. Even as it diminishes, the power Microsoft has over the computing industry is enormous and cannot be ignored.

I have a strong suspicion many phone vendors wouldn't bother to offer WP7 products without some sort of incentive from Redmond.

</comment></comment></comment></comment><comment><USER25> A lot of misinformation being spread here. Microsoft has not BANNED Firefox in Windows 8. There will be a version of Firefox for all editions of Windows 8, including desktop and tablet as long as Mozilla chooses to make one.

In Windows 8 for ARM-based tablets, applications like this have to run in a sandbox (Metro UI). Get over it. Either consumers will or will not buy a tablet that they can't run applications the way they wish. Perhaps a Windows 8 tablet will be a disaster and all this outrage will be for nothing.

Certainly the restrictions Apple places on iOS are in many ways worse. I don't see how you can be mad at Microsoft but give Apple a pass.

<comment><USER26> The "sandbox" disallows JITs. That means JS performance in any browser (other than IE) will be basically unusable, effectively banning browsers from ARM Win8.

<comment><USER13> ... and irreparably damaging their reputation when compared with IE.

So, no. I don't buy that "We don't want to ban your app, we just want to make sure it disappoints your users" as fair.

</comment></comment></comment><comment><USER27> Considering that Apple hasn't been legally ruled to be an illegal monopoly and Microsoft has, the faux-righteous-indignation in the headline completely backfires.

<comment><USER28> Apple also has a lot more...vocal (dare I say 'zealous'?) followers trying to quell criticism. Those very same people will however gladly take every stab they can at Microsoft.

(I think both companies deserve every bit of criticism for trying to repeat history all over again...)

<comment><USER29> Microsoft had an abundant supply vocal apologists back then. Moreover, they had the tech press (which was on paper at the time) in their pocket.

</comment></comment></comment><comment><USER30> As much as I love iOS, I'm sad of some of the comment saying it's normal for Apple to block Chrome/Firefox for security reasons. Tablets (arguably, only the iPad, really) are the future of computing, like it or not. Having a single browser on highly connected machines is shoking.

The whole lockin is understandable, the plateform is relatively new, and proved to be successful in part because if these extreme protections.

But sooner rather than later, Apple is going to have to open some stuff. Being with something like gae keeper on iOS could allow to (very few) browser vendor to get on the App Store with full access to the sysem. Mozilla and Google build solid products with few security issues (if you factor off the security bugs from plugins)

iOS is a very modern OS, but will deeply profit from competition in the browser space. Apple too. The best tablet for apps _and_ web browsing will win in the long run, because the web will win in the long run, but people will always prefer native apps for specific stuff.

</comment><comment><USER31> Windows 8 is the natural successor to Win7 and XP. It's the next version of the most popular desktop OS in the world. As with Windows 7 and OSX, it should run whatever the hell the machine's owner wants it to.

iOS is a locked-down, consistent, homogeneous user experience on specialty devices that should not be and are not marketed as replacements for computers. Apple Store employees will specifically advise against purchasing an iPad as a primary computer.

If Apple tried to tell me what I can and cannot run on OSX, I'd be pissed. On mobile, I currently have a choice between superior UX (iOS) and freedom (Android), which are at this stage in the game somewhat mutually exclusive (part of the iPhone's appeal is that There Is One And Only One Right Way To Do It).

For the record, I run Android, but I still want to the option to select a higher quality product if I'm willing to sacrifice what Android does better (turn by turn directions and physical keyboard on the Droid 3).

<comment><USER32> > that should not be and are not marketed as replacements for computers.

Interestingly several of my non-technical friends have taken on iPads as full time replacements for laptops. They only used them to read the news, facebook or watch netflix the iPad does literally everything that they previously had laptops for.

> If Apple tried to tell me what I can and cannot run on OSX, I'd be pissed.

I think the distinction that Microsoft is going for here is Win8 arm = tablets = iOS, Win8 x86 = laptops = OSX. By your argument there should be no problem with them locking it down then.

<comment> jack-r-abbit The idea that an iPad can perform all the functions that some people are (under) using a laptop for doesn't mean that an iPad is an adequate replacement for a computer. They should not be marketed as such.

<comment><USER13> It all depends on what you use your computer for.

For me it wouldn't be an adequate replacement - I like to work on my code offline and run development servers of my computer, but it's easy to imagine a simple setup where I log on to a remote machine through the tablet and work there.

<comment> jack-r-abbit I'm pretty sure we are agreeing here. If they don't do everything a computer does, they are not a replacement for a computer. If they do everything _you_ do on your computer then they are a replacement for _your_ computer.

</comment></comment></comment></comment></comment><comment><USER33> >"The difference here is that Microsoft is using its Windows monopoly power in the OS market to exclude competition in the browser market."

Some might see it that way. Personally, I don't think that's Microsoft's goals at all, it's just an unintended consequence of them trying to slowly phase out the Win32 API and Desktop applications, and switch entirely to Metro-style WinRT-based apps.

<comment><USER26> That would make sense except that they specifically exempt their own browser from the restrictions that will apply to every other browser.

<comment><USER2> The problem is that third party applications can cause security and performance issues and it's Microsoft who ultimately takes the blame for it. They exempt their own browser because it's their own browser.

<comment><USER33> I'd say it's more an exemption for their own rendering engine. IE10 is more than just a "browser" in Windows 8, it is the engine used to execute several Windows 8 applications.

<comment><USER34> It's an exemption for whatever is preinstalled on the device :) The actual technical mechanism behind this "ban" is simply that installing desktop apps in general is blocked on Windows RT. A "Metro style enabled desktop browser" (what Metro style IE and Metro style Firefox are) is really just a desktop executable that acts like a Metro style app.

</comment></comment></comment></comment></comment><comment><USER35> Meh, it is just time to accept that Android, iOS and Windows RT are not a serious OSes but an unobtrusive, eye-candy cloud clients for masses. The step ahead is either to waste money on VPSes or just demand the right to have full control of the software on hardware we buy -- say Angstrom will always run Firefox without any doubt.

<comment><USER36> You're totally right there, but sadly group dynamics will make it extremely hard for Angstrom to achieve critical mass as a phone OS and have a significant amount of businesses working in its ecosystem.

I'm totally for it but it's not cost effective for me to get a machine capable of running Armstrong, then hack away until I can get it into a workable state (I'm older and busier now...) over just getting an Android, root it, make a throwaway google account so Google cannot pry on my data, and use that instead. It's still some work and some cost but nowhere as much.

If there's a community effort to make it into a click-and-install Android- wiping mobile phone OS, I'd love to help with that in my spare time. Last time I looked into it (waited for years for my OpenPandora until I gave up) Angstrom was stuck in amateur PDA land, things have moved on and we now have cheap smartphones and tables that are basically overpowered PDAs with extra features and they are available for relatively very cheap. To compete with that a massive re-focus would be necessary. Obviously there is no substitute for freedom, so the niche is there.

</comment></comment><comment><USER34> arguments of the form "why aren't you complaining as much when X does it?" are always lame. because (1) often they are, you just haven't noticed it (often because it hasn't resonated with a media echo chamber) and (2) so what.

</comment><comment><USER37> This is such a tired argument. Microsoft's market share on browsers, desktops, etc. has been headed straight south for years, and yet Mozilla continues to beat the drum about choice and innovation and such? Hey, 1998 called, they'd like their complaints back.

Mozilla isn't going after Apple because they can't -- they don't have a hammer of government oversight to pound away to get someone else to do things on their behalf. Mozilla is going after Microsoft mostly because they can get away with it.

These complaints were relevant years ago, but much like Microsoft itself, they're reflective of an old mindset that's fading away.

</comment><comment><USER38> My thoughts in summary: what a difference a name makes.

iPhone runs iOS; most people don't even consider it OSX, so expectations about what apps should be there aren't based on precedence.

"Windows 8 on ARM" /sounds/ like just another platform (out of many) that Windows has been ported to. The expectation is usually based upon what the software vendor can be bothered to port, rather than what Microsoft does.

So to me it's easier to understand why people would have different expectations compared to Apple on this. Change the name and don't include any legacy UI if you want a more direct comparison to be more obvious.

</comment><comment><USER39> Apple has been consistent in it's policies. It has always been a closed castle. That is one reason why I haven't spent any bucks buying Apple products. One good thing about their consistency is that their browsers and other software is pretty good. Safari is much decent browser than crappy IE.

Microsoft on other hand has always grown with partners. They are not a closed castle. So when they try to gag a great software like Firefox I am upset.

This comes at a time when Linux based OS like Ubuntu are perhaps as good as Windows 7. MS is hurting itself.

</comment><comment><USER40> Of course, there _are_ other web browsers for iOS: <http://news.ycombinator.com/item?id=3961084>

<comment><USER7> But no alternative rendering engines (all the alternative browsers are just UIWebViews save for Opera Mini which Apple don't classify as a browser since it doesn't do any rendering locally), and the alternative browsers have worse performance than Safari due to the sandbox disallowing some optimizations allowed in Safari.

</comment></comment><comment><USER41> Why are they blocking FF? It seems to me Apple's inviting the same anti-trust problems Microsoft had. Just let FF on and compete.

<comment><USER42> A browser is a huge attack surface. It's excluded for the same reason Flash and Java are excluded.

BTW I think this justifies Microsoft's stance too. The big problem is that Microsoft has this nasty track record.

<comment><USER43> so we can trust IE to be much more secure and not have problems?

<comment><USER42> No, but ie + other browsers is guaranteed to be less secure than just IE.

<comment><USER44> Not if you don't use IE

<comment><USER42> IE will be used as a browser widget at API level by third party apps, so using it will be almost unavoidable.

<comment><USER45> I suspect it's likely that apps that wish to use an alternative rendering engine for untrusted content would use IE only for trusted content.

</comment></comment></comment></comment></comment></comment></comment><comment><USER46> Has MSFT given any justification on why they are banning Firefox from Windows 8?

And why iOS doesn't allow FF too?

<comment><USER47> They're not banning it. They're just not allowing access to critical API functions for a JIT engine to Windows Marketplace apps. Only IE has access to it. Without these APIs then Firefox will run like a dog because it'll undue all the years that people have been working on optimizing Javascript engines.

<comment> jack-r-abbit Right. So... I don't ban anyone from my swimming pool... everyone is welcome. But if you're not family, you have to wear this 100lb ankle weight. Dive right in everybody! lol

<comment><USER47> I think there is a big difference between banning it outright (like Apple) and hampering it. From the end-users point of view both suck, but at least if I use Firefox to sync my bookmarks and passwords I'm able to on a Windows tablet. Nothing I can do on an iPad.

<comment> jack-r-abbit First, let's assume the majority of users are not going to know why the an app is not allowed and/or why it is sluggish/limited/hampered/etc. From the average user point of view... the biggest difference to me is that when it is banned, the _banner_ (Apple) is the bad guy for not letting it in. When it is severely hampered the bad guy appears to be the _creator_ (Firefox) for making a crap app when in reality the _hamper-er_ (Microsoft) is the bad guy for crippling the app's ability to perform as well as it can.

</comment></comment></comment></comment></comment><comment><USER48> Only one of the organizations involved here has a court mandated consent decree.

</comment><comment><USER49> The key difference is that its iOS on Apple hardware vs a general OS.

</comment><comment><USER50> I would like to take the time to point out that Opera has a browser on iOS [http://itunes.apple.com/us/app/opera-mini-web- browser/id3637...](http://itunes.apple.com/us/app/opera-mini-web- browser/id363729560?mt=8) (iTunes)

<comment><USER51> Opera Mini doesn't contain a rendering engine or JIT or...it's a glorified image viewer that lets the rendering be done on a remote server.

</comment></comment><comment><USER52> I don't think Apple blocks Firefox on iOS. Other browsers like Opera exist in the App Store, maybe Mozilla just hasn't developed FF for iOS yet? Or am I wrong?

<comment><USER2> Apple blocks all non-Safari browsers from the store. Opera Mobile doesn't exist in the App store, only Opera Mini which uses a remote server for rendering. Other browsers in the store use iOS webkit and are effectively shells around the Safari rendering engine.

<comment><USER53> What's wrong with the webkit rendering engine?

Chrome started as "effectively a shell" around webkit. As far as most end users are concerned, the difference between browsers is the UI, not the rendering engine. I use iCab on iOS for its UI and amazing feature set (including Adblock and extensions), and apprececiate the choice. In fact, it syncs with Firefox bookmarks. Atomic is also nice.

It would be very interesting to do a Firefox-like UI for iOS and see what the end user uptake would be.

<comment><USER2> One example: The iPhone webkit doesn't support text reflow even though it's supported by webkit on Android and in Opera.

Many years ago you could have said "What's wrong with the IE rendering engine" because, at one time, IE was the best browser available on Windows.

</comment></comment></comment></comment><comment><USER54> I think a big part of the history which people are forgetting here is that there were certain actions which Microsoft engaged in that strengthened the determination of "monopolistic" behavior. Namely, the restraints and difficulty they created for other operating systems in the market. [1][2]

This specific instance ignores that particular history, and focuses just on the "browser included, supported, and otherwise enabled with the most features" part of the argument, which by its self does not seem to stand on its own merits. And, in fact, there really is -no- difference here between Apple and Microsoft - both have created a specific version of their software for a specific hardware platform, and both have placed, or are placing restrictions on what software can run on those platforms with the stated goal of controlling the end-customer experience.

There is not yet any evidence of undue influence on the part of Microsoft to prevent, or otherwise make too costly for, other operating systems, with other browsers, to be installed on ARM-based hardware sold in the market place. In fact, at this point, it seems to be exactly the opposite - that all existing ARM-based tablet style devices currently for sale in the market contain non- Microsoft operating systems, and very few ARM-based phone style devices contain a Microsoft operating system. One would do well to remember that it was the sum of all actions which led to the anti-trust case, not just preventing IE from being uninstalled effectively, or preventing Netscape from being installed at the same level and with the same capabilities as IE.

In this case, there is no evidence that MS is taking other actions to prevent people from selling arm-based devices with other operating systems. Given that we accept that it is legal for other entities to restrict what 3rd party software may be installed on their devices so long as they don't apply undue influence on the market outside of their product, I don't see why the reasoning would be so different here.

[1] <http://en.wikipedia.org/wiki/United_States_v._Microsoft> "... Microsoft's conduct in forming restrictive licensing agreements with original equipment manufacturer (OEMs), and Microsoft's intent in its course of conduct. "

[2] <http://www.justice.gov/opa/pr/Pre_96/July94/94387.txt.html>

"Exclusionary Per Processor Licenses--Microsoft makes its MS-DOS and Windows technology available on a "per processor" basis, which requires PC manufacturers to pay a fee to Microsoft for each computer shipped, whether or not the computer contains Microsoft operating system software. The complaint alleges that this arrangement gives Microsoft an unfair advantage by causing a manufacturer selling a non-Microsoft operating system to pay at least two royalties--one to Microsoft and one to its competitor-- thereby making a non- Microsoft unit more expensive. "Microsoft has used its monopoly power, in effect, to levy a "tax" on PC manufacturers who would otherwise like to offer an alternative system," said Bingaman. "As a result, the ability of rival operating systems to compete has been impeded, innovation has been slowed and consumer choices have been limited.""

</comment><comment><USER55> Perhaps Apple does it for quality purposes, while Microsoft does it to avoid competition.

</comment><comment><USER56> >Preston Gralla

Not this guy again.

</comment><comment><USER57> But Apple made that 1984 commercial years ago. That means it can do no wrong, right? AND it's so cool. That also means it can do no wrong, right?

</comment><comment><USER12> Best guess, the author is intentionally being dense and stirring up controversy for clicks.

Yes, iOS and Windows RT are similar in some ways. The main difference is that Windows RT is a version of Windows, an OS that is a monopoly in its area. Extending a monopoly to other areas is different than a totally new product. Note that Microsoft is using the dominant position of Windows to further Windows RT, for example by having Office on it and various syncing stuff.

Yes, there are grey areas, and all of this is debatable. It does make sense to give Microsoft more leeway given it is fighting an uphill battle in the tablet space. But the article seems to ignore all of that.

<comment><USER13> > give Microsoft more leeway given it is fighting an uphill battle in the > tablet space

So, if we make it really hard to rob a bank, we should be OK with someone robbing one. The fact it's an uphill battle does not make it less an abuse of monopoly to extend it into other markets than it would be if they managed to see this opportunity before others (or not failed miserably to execute on it, over and over again).

It's only an uphill battle because they were incompetent to see the opportunities Apple saw and to execute as well as Apple did.

<comment><USER14> I think what OP meant was that Microsoft should not be hobbled with deadweights compared to, lets say a startup competing in the tablet market. I don't believe he was talking about special incentives.

Competition is almost always good, especially seeing that Android tablets are hardly making any traction and even Kindle Fire sales dropped like a rock this quarter.

</comment></comment></comment><comment><USER58> #drunken troll comment

"Windows 8 FTW! Dude you are the DON. I really wish there was more people like you writing opinions like this online and make sure Apple gets what they deserved! What a bunch of asshole! Seems to me you should also give Samsung a call, see what they think! After all this they do not have browser either yet on iOS and I bet they really wanted it maximum! Apple should be take a leaf from the real Mr Steve book, and stop making mess of themselves. Shameful really, this is why I always buy Samsung product and Microsoft software, it is best for everyone to avoid this Apple who are never good for anybody. Thank you for great article."

</comment><comment><USER59> I think Mozilla are absolutely right. and there is no hypocrisy. Microsoft are willing to, and _have actually already_ , cause years of stagnation and harm to the internet with IE6. Presumably if they got the chance they would do it again on tablet too. Apple on the other hand don't appear so risky for two reasons:

1) they've never appeared to have an issue with other browsers on Mac OS

2) there's Android and its browser competing with iOS, so there is not a complete iOS-only monoculture like Microsoft had with Windows - there is still competition between mobile browsers (yes, switching browsers means you have to switch device, but that's better than nothing and will surely prevent one mobile browser from stagnating for _five years_ ).

I know this doesn't mean Apple _wouldn't_ do it if they had the chance, but as another commenter pointed out, many people have bad memories of long weekends trying to work with IE6 for the long 5 years between IE6 and IE7. Microsoft have already offended, so they deserve extra special attention, especially with legal agreements possibly still in place due to the antitrust cases.

</comment><comment><USER60> FF's entire existence is based on a hate of Microsoft, so it only makes sense.

That's why they're taking it up the butt from Google Chrome, Mozilla does not know how to deal with them. Nor do they particularly care that much about it, it seems (other than switching to increasing the version number every 2 months).

<comment><USER61> > FF's entire existence is based on a hate of Microsoft

As a student of history I'm sure you are aware that Mozilla (the name and the code base) predated Internet Explorer. I think you meant to say that Internet Explorer's only reason for existing was that Microsoft feared Netscape.

<comment><USER60> I stand corrected, thanks. Read up on the actual history of the browser. Thought today was going to be a day I did not learn something :-)</comment></comment></comment>


Twitter locks your account if you change your display name to Elon Musk - <AUTHOR> https://thenextweb.com/hardfork/2018/07/25/twitter-cryptocurrency-scam-elon-musk/ <comment><USER2> Reminds me of Ancient China where no one could have the same name as the Emperor, or even use the same characters as his name.

</comment><comment><USER3> What about Melon Usk?</comment>


GorillaScript - jarek-foksa http://ckknight.github.io/gorillascript/ <comment><AUTHOR> Wow, some of these features sound really cool!

As a small complaint: After seeing about a dozen compile-to-JS languages, I don't care about the full list of features anymore. Please add a big note at the top saying how this is _different_ from other compile to JS languages. Why save all the good stuff (typing, promises, currying) for the last half of this massive page?

<comment><USER2> I came here to say this.

<comment><USER3> I second that, just WOW. Someone wasn't satisfied with removing semicolons and curly braces and fixed the ENTIRE language instead. WOW!!

</comment></comment></comment><comment><USER4> Holy cow. It's built on macros, and macro-friendly! And I can use it with the node.js ecosystem!

As a guy who built his own npm-installable macros.coffee, [0][1][2] I am torn.

I love macros enough that I felt I _needed_ to have them in JS-family languages, which have few metaprogramming options outside of tricks on 'this', which is why, when I saw that CoffeeScript had clean syntax and a relatively clean AST, I made it my "learning node/npm" project to add them.

On the other hand, my project is simple because it depends on a fragile hack: running a deep-copy on a chunk of AST for 'quote'. It's a fragile hack that jashenkas could break with a single well-placed closure, and as I promised on my project page, "If you want to ... build a substantially more 'heavy-duty' implementation, I'll probably end up using yours." This isn't an implementation in CoffeeScript, but it's better -- it's actually built into the language (as macros work best as a core language component; once you have 'em, it's easiest to write your language with them).

I'll have to try out GorillaScript and see what it actually feels like to write code in the language, allowing for the fact that its syntax may not be as pretty as coffeescript yet. But I wouldn't be surprised to find myself using GorillaScript this time next year.

Macros++.

\-----

0) github.com/mrluc/macros.coffee

1) [http://mrluc.github.io/macros.coffee/docs/macros.html](http://mrluc.github.io/macros.coffee/docs/macros.html)

2) [https://npmjs.org/package/macros.coffee](https://npmjs.org/package/macros.coffee)

<comment><USER5> Interesting work. Once I refactored GorillaScript to be pretty much fully macro-driven, it made everything super-nice to deal with. Every single syntax construct in GorillaScript is a macro, even `if` and all that stuff.

</comment></comment><comment><USER5> If anyone would like to look at the slides for a presentation I did on GorillaScript, here you go: [http://ckknight.github.io/gorillascript- presentation/](http://ckknight.github.io/gorillascript-presentation/)

In it, I discuss some of the design decisions. Sadly, there wasn't any video, so I don't actually go in-depth in the slides themselves.

<comment><USER6> This looks like CoffeeScript had a baby with Rust, and I'm seriously tempted to switch from the former for my latest project. It has all features for which I am still considering adding specialist libraries to CS (promises, macros, and a bunch of ES6 stuff.) Insanely great work! The latter parts of the slides where one slide == one feature helped me have a feel for the language better than the text docs.

</comment></comment><comment><USER7> I would prefer some compiled JavaScript ECMAScript 6 that and could be compiled into compatible JS. So I can use all the goodness like classes and iterators. Without having to deal with polyfills.

Please somebody...

<comment><USER8> [https://github.com/google/traceur- compiler](https://github.com/google/traceur-compiler)

Requires a runtime, though.

<comment><USER7> It can be precompiled but it has not been optimized to do so: [https://github.com/google/traceur- compiler/issues/307](https://github.com/google/traceur-compiler/issues/307) It seems the project is not very active.

<comment><USER8> It requires a runtime even after compiling: [https://github.com/google/traceur- compiler/wiki/CompillingOf...](https://github.com/google/traceur- compiler/wiki/CompillingOffline)

> The code generated by Traceur depends on a small runtime library containing > Javascript code for things like creating classes, handling spread arguments, > etc. To use code compiled from Traceur, you'll need to include that too.

<comment><USER9> That doesn't sound so bad if it works well, though, right? Kind of like including jQuery so you get cross-browser code.

</comment></comment></comment></comment></comment><comment><USER10> Massive work.congratulation for achieving this.

My main concerne is with optionnal typing ( which is my only real concern with javascript at the moment ) : it says that types are checked at runtime.

Does this mean i still have to run unit tests that goes into all my code before i can be sure i don't have a type error ?

<comment><USER5> Yes, you would, at least in the current state of things. I do plan on adding some compile-time checking (without getting in the way), but it's not there yet.

</comment></comment><comment><USER11> While this is an interesting effort, I can't help but be squeamish about the sheer volume of JS that gets emitted (due to type checking) for what seem like small amounts of input.

<comment><USER12> Wait, the type checking isn't static?

<comment><USER5> Currently, no. I do plan on adding warnings (not errors) on a statically- calculated type issue. One thing is that I don't plan on it erroring if you call a function with a value whose type might be an "any" type or a "union" where it expects a specific type. If there's some overlap, it would allow, to make things easier and give the programmer the benefit of the doubt.

Thus, the following would compile without warning:

        let double(x as Number) x * 2
        let repeat(x as String) x & x
        let fun(x as Number|String)
          if is-number! x
            double x
          else
            repeat x
        let fail(x as Boolean)
          // this should fail at compile-time
          double x

I could write the compiler to be a lot smarter and have it track types through conditional branches (which would be very hard, but possible), or allow it in those cases where it is possible that the types overlap.

I also might add a "cast", i.e. a runtime type check. I'm not sure what the best syntax for it would be, but it would act like the following:

        CAST(x, Number) // validate that x is a Number or throw a TypeError
        CAST(x, Number|String) // validate that x is either a number or a string, otherwise throw TypeError
        CAST(x, Number, 0) // validate that x is a Number, otherwise evaluate to 0.

Of course, in the cases where `x` could not fit the type requested, then that could error at compile-time.

I would love some feedback on this, especially from the perspective of "what would I use to help me develop", not "I need my program to be 100% statically type-safe without having to do any testing".

<comment><USER12> The feeling of it reminds me a bit of Erlang's success typing, but I don't know enough to say much more.

</comment></comment></comment></comment><comment><USER13> Wow, I wish this is what coffeescript was. This has most of the niceties of coffeescript and adds immutability, types, and macros.

I will end up sticking with TypeScript though for anything at work since the type system has more capabilities right now and it is just Javascript with types so it is very simple to use for those with Javascript experience.

<comment><USER14> What do you mean when say that you wish CoffeeScript was this? I mean GorillaScript exists, so if you prefer it to CoffeeScript then use it rather than CoffeeScript.

<comment><USER15> The difference is that CoffeeScript has a massive amount of mindshare, integrations, and tooling. GorillaScript may be better than CoffeeScript but that doesn't mean that it's even remotely close in terms of day-to-day usability. Because CoffeeScript got there first (and was decent) it's got a huge head start on ANY other competitor.

<comment><USER16> Yes, but that's like saying Perl got there first before Python or Ruby. GorillaScript, CoffeeScript, TypeScript, etc. all basically use Javascript as a platform, and there should be room for all of them in the long run. (Or, at least room to let the market sort out which ones they like the best).

BTW, this got me thinking: are the Javascript envine vendors (V8, etc.) doing anything to make it easier to write languages like GorillaScript or CoffeeScript? Or is it all up to the language designers?

<comment><USER5> They have made serious effort with developer tooling, especially with Source Maps.

</comment></comment></comment></comment></comment><comment><USER17> With such a kitchen-sink list of features, I can't believe he left out _named parameters_ (seriously) and refinements (sarcastically).

Though this is definitely the best compile-to-JS language and I'd choose to use it if I'll ever feel safe enough using anything else than plain Javascript.

<comment><USER5> For named parameters, this is the best one can do in JavaScript without constructing a fully static type analyzer:

let use-named({ name, age }) ->

use-named(name: "ckknight", age: 25)

For refinements, what are you referring to?

<comment><USER17> Ah, destructuring is so sweet!

You're right, it's no real need for it and it's unfeasible because you need to either (a) fully static type analyze everything or (b) what anonymous just explained... and they're both out of the question.

The refinements thing was a joke, in the spirit of what else can one add: it's a controlled form of monkeypatching / classboxing about which a lot of fuss was made in the Ruby community after Matz decided to add it to the language ([http://timelessrepo.com/refinements-in- ruby](http://timelessrepo.com/refinements-in-ruby)), mainly because it's very hard to implement without creating more problems, even if you have your own interpreter to hack on (short answer: don't bother looking about it and even if you're smart enough to figure out a way to add it to a compile-to-JS language, don't waste your effort on it - they're not an anti-feature and they could make sense in languages that allow monkeypatching, like JS and Ruby, but they're too much work for too little benefit and too much possibility for bad use and unneeded complexity).

<comment><USER5> Actually, here's a better example, if you want defaults.

Also nice is that it doesn't have to create a full defaults object at runtime, and each binding would only be evaluated if individually needed:

        let func-with-named-params({
          id as String // TypeError if not a String
          metadata // don't care about type, defaults to void
          seed as Number = get-random-seed() // requires a Number, only calls function if not provided.
        }) ->

You can do all sorts of things with object destructuring.

Yeah, Refinements seem like a similar thing to extension classes in .NET where methods defined somewhere else affect a class but only if included, without polluting the globals.

The only possible way I could see supporting something like this is with a different method call operator, so something like:

NOTE: The following is theoretical code. It does not work in GorillaScript 0.9.x, but might be implemented if there is enough positive feedback for it.

        refinement String
          def repeat(count as Number)
            if count < 1
              ""
            else if count < 2
              this
            else if count bitand 0b1 // if it's odd
              this->repeat(count - 1) & this
            else
              (this & this)->repeat(count bitrshift 1)

        // and used as such:
        "Hello "->repeat(5) == "Hello Hello Hello Hello Hello "
        // would turn into this code:
        String_$_repeat("Hello ", 5)

        let unknown(x)
          // This would throw a compile-time error, as x's type
          // would be unknown. It would have to be a single
          // named type that has a refinement defined, either at
          // the top of the file or with an import.
          x->repeat(5)

Also, refinements could have macros on them, so one could do

        "Hello"->for-code-point point, index
          // This is a body in a macro defined as "for-code-point" on a String refinement.
          do-something(point)

So, this would be a nice way to have refinements, but have the terrible downside of requiring the type to be statically known.

You could also define a refinement on a union type or even an object type, such as the following:

        refinement Array|{ length: Number }
          // define a getter, why not?
          def get median()
            this[this.length \ 0]

          macro loop
            syntax item as Identifier, index as (",", index as Identifier)?, body as Body
              index ?= @tmp \i
              AST
                let mutable $index = 0
                while $index < @length, $index += 1 // it knows that `@length` is a Number, no need to type checking
                  let $item = this[$index]
                  $body

          def each(callback)
            // look, we're using the macro we just defined!
            this->loop value, index
              callback value, index

The refinement namespace would not conflict with the normal invocation namespace, so you could have `"Hello".same()` and have it be exactly as expected, but `"Hello"->same()` not, because it would turn into `String_$_same("Hello")` (or something like it).

To clarify before, the following would work:

        refinement Number
          // automatically knows it returns a Number
          def log(base as Number = Math.E)
            Math.log(this) / Math.log(base)

        let alpha = 1e100->log(10) // knows that 1e100 is a Number, obviously, and since ->log returns a Number, alpha is automatically known to be a Number.
        let bravo = alpha->log(10) // knows alpha is a Number, etc.
        let charlie = Math.pow(2, 10)->log(2) // since we know Math.pow returns a Number, we're good.
        let delta as Number = some-library.some-unknown-method()
        let echo = delta->log() // we specifically declared delta as a Number, so we can use ->log

        let foxtrot = [1, 2, 3]->median // Array subtypes from { length: Number }
        let golf = "hotel"->median // Hey, so does String!
        let india = arguments->median // And so does Arguments
        let juliet = { length: 4, 2: \kilo } // And so does this custom type
        let lima as { length: Number } = some-outside-source()
        let mike = lima->median
        // assuming I come up with a "cast" operator, i.e. type-
        // check with error or default value
        // this would allow a String, Array, etc., would check
        // at runtime (but not in production, with
        // DISABLE_TYPE_CHECKING set to true)
        let november = (some-outside-source() as { length: Number })->median
        // require that the result is an array, otherwise
        // evaluate to []. The default could be an expensive
        // operation that is only executed when necessary.
        let oscar = (some-outside-source() as Array = [])->median

        // unknown is of the "any" type, representing all
        // possible values, including null and void.
        let unknown = some-library.some-other-method()
        // Since unknown isn't at least { length: Number }, we
        // don't know that ->median should map to our refinement
        // { length: Number }->median and thus cannot be used
        // without casting.
        let wrong = unknown->median

I dunno, something to think about. Would people want to have this feature?

</comment></comment></comment></comment><comment><USER18> 1 & 2 == "12" \- Now THAT I call unexpected behavior. :-/

Interesting language though.

<comment><USER19> In what way is that unexpected, given then & is string concatenation?

<comment><USER20> & is normally (= in C) a bitwise operator, not a string concatenation. Especially looking strange for me when it makes a string out of two numbers.

<comment><USER5> I never claimed for GorillaScript to be a C-like language, because at its core, stripped of syntax, JavaScript is not a C-like language.

It more resembles LISP with its macros and closures with nice syntax built around those concepts.

I tried to make all the operators match their closest arithmetic, mathematical equivalents. Thus using `^` for exponent and `+` for addition. Since JavaScript does not support bitwise operators cleanly, needing to cast to int32 and generally being disued, I felt they could be better aliased with `bit`, freeing up those operators. Since string concatenation needed some operator as a building block for string interpolation, the freed-up `&` was a ripe candidate for it.

That all said, string interpolation is the typical use case for creating strings, so feel free to just use that if possible. Anything more than that and you might need a templating engine.

<comment><USER3> What do you think about not using any operator (but space+"") for concatenation and using a syntax like this:

        var 1   = 5+5 // I would expect: Error 0-9 cannot be used as a variable
        var foo = "Hello " "Bob!" "\nAre you there?"
        var bar = "Hello " 1

        console.info(1) // throw error and refer to var 1

        console.info(foo)
        "Hello Bob!
        Are you there?"

        console.info(bar)
        "Hello 1"

<comment><USER5> Juxtaposition as an operator is already used by function invocation, e.g.

        f "Hello"

If f were a string, how would I know I wanted to concat it instead of calling?

<comment><USER3> By not making () optional. Honestly I get why people hate curly braces, but parenthesis are important, removing them makes a new language hard to understand, making it optional makes the language (horrible or) simply weird and non-deterministic.

There is ZERO technological or efficiency related benefit in making () optional, it just makes your grammar parser more complex and slows down compile/interpretation time.

If I would have time and no specs given, then I would write a compiler for Sanskrit. It's one of the oldest languages and as accurate as AI Agent languages. Really accurate. Just google for "Sanskrit Artificial Intelligence" and you will find very interesting publications. Here's something by NASA: [http://www.vedicsciences.net/articles/sanskrit- nasa.html](http://www.vedicsciences.net/articles/sanskrit-nasa.html)

Btw. I've written a simple language+vm in C already using bison,flex etc. Our Prof and other students made a custom CPU that runs on a custom OS made for this language called Ninja. A friend of mine extended it by Object Orientation later.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I have no claim to be an experienced developer or so, just asking for opinions: doesn't this huge number of complex features implemented in modern programming language give you a feeling of something being wrong? And why?

<comment><USER3> No it doesn't. It gives you freedom to do things naturally, but you will only understand how to solve a problem naturally, when you've understood "programming in general" or "Computer Science", without specifics to a programming language.

To take fear away, you can easily create very very complex stuff with a single language feature. Think about QBASIC, one would think that you cannot do anything except some command-line programs with it. See the complete opposite: [http://www.pcworld.com/article/2033318/black-annex-is-the- be...](http://www.pcworld.com/article/2033318/black-annex-is-the-best-qbasic- game-youve-ever-seen.html)

</comment></comment><comment><USER22> >> x and= y - Same as if x then x := y

I'm having trouble imagining when you'd need to do this. But oh well..

>> There is also a short syntax for single-word strings that also convert dashed-names to camelCase just as normal identifiers do.

I'd like to see an example of this. I don't think I quite understand what it's meant to do.

>> Binding access

I would have preferred: f@obj (arg1, arg2, arg3) for function application over: f@ (obj, arg1, arg2, arg3)

Other that that, I can certainly appreciate the huge amount of work involved in creating this and I wish them success.

<comment><USER5> and= isn't all that useful, I agree, but it would be odd to leave out given that there's or=, ?=, ownsor=, etc.

\alpha-bravo-charlie == "alphaBravoCharlie"

Well, since GorillaScript doesn't require parentheses for invocation, you'd need to have some delimiter between the context and the arguments or have to wrap one of them. Why not simply just use "," as the delimiter and then you can treat it as if doing .call/.apply?

<comment><USER22> > Well, since GorillaScript doesn't require parentheses for invocation, you'd > need to have some delimiter between the context and the arguments or have to > wrap one of them.

Well, I was trying to think why you'd even need a delimiter. I thought the absence of the comma between the context and the first argument would disambiguate:

      f@x (a, b, c)

would be written as:

      f@x a, b, c  // Comma between a and b

While:

      f@(x a) (b, c)

would be:

      f@x a b, c  // No comma between a and b

Then again, a call like:

      f@ a b c d, e

would be ambiguous, so on second thought I think you've made the right decision.

Heck, even the non-ambiguous cases seem easier to mentally parse with the comma there.

So I retract from what I said. I should have thought this through before posting.

Edit: I see you've also added the example of dashed-names to camelCase conversion to the page. Thanks, that helps. Edit2: formatting.

</comment></comment></comment><comment><USER23> So overall this is an interesting take on Javascript. I like that much of it gets precompiled away (constants, etc). I'm not so fond of "&" being string concatenation. I like Perl6's "_" better, it reads well. Also:

> || - or, can no longer be used with and unless one group is in parentheses

Seriously? Do you require the "+" and " _" operators to have parentheses around them? Why do people think order of operations is hard with "and" and "or"? I _really* don't get it (and _always_ turn off compiler warnings about that when working with C).

Also, "ownskey" is a bit of a mouthful. Why not ".?" ("?." would be "get key if object isn't null")?

<comment><USER5> Most of the time, string concatenation is unnecessary with interpolation: "$alpha $bravo" means alpha & " " & bravo.

The reason `and` and `or` are best in parenthesized groups is that it creates confusion in the precedences otherwise. asking someone what `alpha and bravo or charlie` means can be confusing if there's no obvious grouping (like a standard mathematical operator's) giving `and` more precedence than `or` or the other way around.

You actually can use `!.` as an "owns access", as used in `alpha!.bravo`, which means `if alpha ownskey \bravo then alpha.bravo`.

And yes, `?.` means an "existential access", as used in `alpha?.bravo`, turns into `if alpha? then alpha.bravo`.

You can also mix these with `?!.` and it works as expected. :)

<comment><USER23> The thing about "and" and "or" is that there _is_ obvious grouping--it stems from boolean logic where there is an order of operations ('or' is like '+' and 'and' is like '\\*'). There's really no excuse to pander to people that can't or won't memorize the order of operations for boolean logic.

BTW, I don't like coming across super critical, but this is a pet peeve of mine. This particular issue really gets under my skin (I always pass -Wnoparenthases to gcc). Overall I am very impressed with Gorillascript. I love the macros, the functional programming stuff and the basic terseness of it all.

</comment></comment></comment><comment><USER24> Looks very interesting! The features that caught my attention are:

        * immutable values
        * cascades
        * try/catch/else/finally
        * promises
        * async
        * optional typing
        * curreid functions
        * generics

</comment><comment><USER25> This seems to fix every small issue and even a few large ones that I had problems with in JS! It seems like it will be super easy to integrate with my current "build tools" for the few dynamic languages I run (built into Komodo as macros and plugins).

Heck, I could probably write the build tools plugins in Komodo WITH GorillaScript. Of course, not quite the same as a brand new self-hosted compiler, but I'd like to think that it's circular-referency is adequate to be in the vein of functional programming tradition :)

I was never excited about Coffeescript. This is JavaScript: The Good Parts And Even The Best Brand New Parts

<comment><USER5> I'm very happy you're excited about it. The best thing you could do for me now is to use GorillaScript to make something. Anything. Something big, something small, something with fancy features or minimal ones. I want you to think along the way "how could my life be easier?" "Better typing? Terser syntax? More verbose syntax? Easier async support? Some other fanciful feature?"

Then, file issues on the GitHub tracker with your ideas to make GorillaScript better for you. Or join us on IRC at irc.freenode.net at #gorillascript. I (ckknight, author of GorillaScript) try to be there as often as I can, but I do have a life outside of IRC, for now...

</comment></comment><comment><USER26> Why would I use this over coffeescript/underscorejs?

<comment><USER27> Yes I'd like to know too. As the top post mentions, the documentation really needs to hightlight the benefits over established popular libraries.

</comment></comment><comment><USER28> This seems like the Python of compile-to-JS languages in much the same way CofeeScript is the Ruby. Not a big fan of Python but I can see this becoming popular with Python WebDevs.

I kinda hope this doesn't become a trend though, every web development enviroment spawning its own compile-to-JS language. I feel that there are too many such languages already.

<comment><USER17> I think it's closer to "the Scala of compile-t-JS languages" :) ...last time I checked Python didn't have macros and syntax for currying, function composition, piping etc. and its TIMTOWTDI philosophy seems closer to Ruby.

Honestly, the macros section scared me out, especially the "there are _five_ types of macro syntaxes" (...this is as far away from the pythonic way of doing things as one can get) but this seems the most promising compile-to-Js language I've seen.

<comment><USER5> Macros can be scary. The need for five different syntaxes is because in a non- homoiconic language, positioning and syntax matter, so having an infix operator would be defined differently from a call-like macro. They all act fundamentally the same, it's just how you define the syntax of how they are used that is the difference.

</comment></comment></comment><comment><USER29> When using this for development, what is the workflow? I write something in GorillaScript, compile it and run it in the browser. Is there anything like (GS) source level debugging so that I don't need to figure out the correspondence between the GS source and the JS in order to, for example, set a breakpoint?

<comment><USER7> That is where _source maps_ come into place. Not sure about support for GS though.

<comment><USER5> GorillaScript has full support for Source Maps, as any good compile-to-JS language should.

</comment></comment></comment><comment><USER30> While this is actually really awesome, I think a lot of the nastiness of JS can be dealt with by using a good JSHint plugin for your text editor (that highlights errors/etc as they happen). Hoisting, function scope, ==, var, using variables without defining them, etc - it'll catch many things.

<comment><USER5> If I ever write JavaScript, then I definitely use JSHint. It doesn't help with some things such as immutable local bindings, type checking, not having to worry about hoisting, or any of the nice syntax features you get with GorillaScript, which is why I see the benefit.

</comment></comment><comment><USER31> Looks interesting.

The section on "Optional Typing" is too brief. Type inference is mentioned, but there are no details on how the type system functions and what a failure of type checking means. It seems one can't name types, which is odd and will lead to a great deal of repetition.

<comment><USER5> Types are allowed to be any of the primitive types (e.g. Boolean, Number, etc.), null, undefined, any custom "class", a specifically-typed array (e.g. [Number] for an array of numbers), or a specifically-typed object (e.g. {x: Number, y: String}). I do plan on being able to alias the typed object as an "interface", just haven't gotten around to that.

A failure of type checking generally means you get an early runtime error, though I plan on reworking things to catch more at compile-time (while still not being a pain).

<comment><USER12> How do types work with objects and classes? Can you subtype?

<comment><USER5> Yeah, class Child extends Parent

</comment></comment></comment></comment><comment><USER32> Dashed-identifiers is probably my favourite feature. I've personally defined the <leader>f chord to emit an underscore in vim just to save myself the trouble of reaching all the way for a shift and a dash.

</comment><comment><USER33> I'm curious about why ckknight started this project instead of contributing to Dart. I see that the syntax is more Pythonic than C-ish. What else distinguishes this language from Dart?

<comment><USER5> Dart reinvents a full type system for itself, with its own environment and paradigms, and if you want to cross-compile to JavaScript instead of running in a dart VM, you have to ship a huge swath of code with it to get it working.

GorillaScript works with the JavaScript type system instead of against it, at least as well as it can, including supporting nice future additions like Map, Set, and WeakMap.

GorillaScript tries to work within the JavaScript landscape as best it can so that there is as little of a disconnect between GorillaScript and JavaScript as possible.

</comment></comment><comment><USER34> Too bad it doesn't have list comprehensions. That's something I sorely miss when writing most mainstream languages apart from Python. (I know CoffeeScript has them.)

<comment><USER5> Actually it does have list comprehensions. You just use a for loop (or any loop) as an expression and it evaluates to an array.

</comment></comment><comment><USER35> There is also Embedded GorillaScript for templating [http://ckknight.github.io/egs/](http://ckknight.github.io/egs/)

</comment><comment><USER36> Now this one really looks like a nice language!

</comment><comment><USER37> Whoa, this actually looks really good. terse, robust and safety first, whilst still packed with some high-level features.

<comment><USER38> Kinda like C# ;)

<comment><USER5> Yes, I take a lot of inspiration (with some leeway for personal taste) from Delphi and C#, so I have great respect for Anders Hejlsberg - who I'm now competing with since TypeScript.

</comment></comment></comment><comment><USER39> There is a small typo in "The outer this can also be captured _be_ appending".

<comment><USER40> Filed a pull request fixing this: [https://github.com/ckknight/gorillascript/pull/101](https://github.com/ckknight/gorillascript/pull/101)

</comment></comment><comment><USER41> Is this the same ckknight who made PitBull, Parrot etc?

<comment><USER5> Yeah, I stepped away from the Lua world to work on JavaScript-related stuff.

<comment><USER42> The same guy who used to hang out on boo irc? Wonder if that's where the macro ideas came from.

<comment><USER5> Yeah, I hung out there. Also contributed a bit. No, most of my macro ideas come from Scheme.

</comment></comment></comment></comment><comment><USER43> "bitand" for bitwise & is weird

<comment><USER5> Bitwise operators for JavaScript are unused except in special cases, as JavaScript really doesn't handle bitwise as one might expect. Everything is cast to either int32 (or uint32 in the case of >>>) and then recast back into a Number (8-bit IEEE-754 floating point). Due to their relative lack of use, freeing up the symbols to represent something else seemed prudent.

<comment><USER44> I've seen them get quite a bit of use in graphical code, which is, well, actually fairly common in JS.

Code that uses bitwise operations looks fairly ugly as is. Hav e you considered enabling them with a prefix or suffix? E.G. ^$ instead of bitxor, or >>$ instead of bitrshift...

<comment><USER5> That could be possible, you could even do it today, if you wanted:

        macro operator binary ^$
          ASTE $left bitxor $right

There are also operators for `and`, `or`, `xor` which act logically. `not` which does a boolean invert. So there are `bitand`, `bitor`, `bitxor`, `bitnot` which fit well as working bitwise instead of logically.

I suppose the outliers are `bitlshift`, `bitrshift`, `biturshift`, but it does somewhat make sense to keep the `bit` prefix because it casts to int32 and because its operations are inherently bitwise.</comment></comment></comment></comment>


Randomly-generated passwords still have to be legal strings - <AUTHOR> https://blogs.msdn.microsoft.com/oldnewthing/20160316-00/?p=93163 <comment><USER2> News flash: taking a randomly generated sequence of bytes and treating it as correctly following some encoding may fail.

This is like saying "Why isn't this random sequence of bytes a valid JPEG file?" If you want a random image, you generate the image randomly, _then_ you encode it. Strings are no different — though the encoding is simpler.

<comment><USER3> Unicode mystifies a lot of people. Many people don't even realize that a sequence of 16-bit unicode value is UTF-16 (or UCS-2), let alone that not all sequences of 16-bit values are valid UTF-16.

The password bit is really just the hook, the main info in this article is the fact that these values are interpreted as UTF-16, and that UTF-16 has requirements beyond "sequence of 16-bit values."

Which is kind of obvious, but still not well known for many.

<comment><USER4> What doesn't make sense though is why the password's bits MUST be a valid UTF-16 string. Password comparison should just be comparing bits and checking if they're equal.

Whether it may just so happen to represent real, correctly typed, English words, or be a valid ASCII string, or UTF-16 string, or whether it was typed it from your keyboard, or generated from a program, these should also be incidental.

<comment><USER3> If your passwords are entered by humans (which is usually what "password" means) then you want to treat it as a real Unicode string so that you can normalize it before you do the dirty work on it. Otherwise you could end up with a situation where, for example, a user's password contains "é" and fails when entered on certain systems because that system composes é differently from the system on which the password was set.

</comment></comment></comment></comment><comment><USER5> I second the "hex encode it" solution, 256 bit of generated hex looks something like this:

232e2252b8d5a294dd8564020f0cf609f511b3d196ed83030ce9615c6737f578

That's readable, typable, copy-pastable. Not very memorable but 256 bits is rarely memorable.

It's still short enough to send around by normal messaging.

This is specifically about randomly generated passwords, this is not about dealing with human generated "must have capitals, not start or end with a number" etc rules.

<comment><USER6> Remember on windows you are effectively stuck with a maximum password length of 15 characters in many scenarios.

And before you Google and say "No! It changed to 127 in Windows XP!", remember:

\- Somewhere on your network, NTLM is being used.

\- Office 365 supports 16 max.

\- Lots of random apps won't work.

<comment><USER7> I think you're wrong.

I login to Office 365 with a password that has over 16 characters. I have similar length passwords in Windows networks that use NTLM. Clearly it works just fine.

<comment><USER8> Just a guess, but I've seen systems that just ignore the extra characters. VNC is one, and there's others.

Example:

Your password is 12 characters on a system that says make it 8 characters or longer. If you type only the first 8 characters of your password, it lets you in. As someone else said, "silent truncation".

</comment></comment></comment></comment><comment><USER9> Is there really any need to generate non-alphanumeric passwords as long as they are of sufficient length? Sticking with plain old A-Za-z0-9 seems like it avoids a lot of interop issues.

<comment><USER10> Every extra supported character makes the solution space much bigger. with 2 character passwords, your set is 3844 combinations. If you can manage to add in "!@#$%^&*()", that goes up to 5184, a 16% increase in options leads to a 34% increase in search space.

No, it's not necessary, unbounded length is probably better. But it's pretty nice to have a lot more characters, and ought to be an easy win.

<comment><USER11> Every _required charter type_ makes the search space dramatically smaller. [https://xkcd.com/936/](https://xkcd.com/936/)

The goal should be long easy to type and remember passwords, adding an extra few digit is worth far more than forcing passwords to look like: 2K#@1j*

Compare say a 20 digit numeric password vs an 9 digit [0-9] [a-z] [A-Z] and special.

<comment><USER12> Usability is key.

Once you hit 12+ characters it is extremely likely that the password is vulnerable to dictionary/phrase attacks combining whole words - or you're using a password manager.

The xkcd is funny - but it's also a terrible password suggestion.

<comment><USER13> Why is it terrible?

Certainly a passphrase consisting of 4 English words is going to be easier to attack than a password consisting of a similar number of random letters. But as long as you judge a password or passphrase by its information content rather than by its length, xkcd-style passphrases can be just as good as random letters, but are likely to be easier to remember.

Plug: I've written a random passphrase generator, inspired by xkcd's [https://xkcd.com/936/](https://xkcd.com/936/) ("correct horse battery staple") that picks random words from a dictionary, subject to requirements you can give on the command line. It optionally tells you how much randomness is contained in the generated passphrase (assuming the attacker knows the parameters you used). Sample output (picking 4 words of 6 to 8 letters):

        $ gen-passphrase -v 4 6 8
        verity nonfat shunted specking
            27405**4
            5.6405e17 possibilities, equivalent to:
            58.97 random bits
            12.55 random lowercase letters
            9.90 random mixed-case alphanumerics
            9.00 random printable ASCII characters

The reported numbers will vary depending on which dictionary you use (/usr/share/dict/words by default). In this case, the dictionary contained 27405 words of 6 to 8 letters.

[https://github.com/Keith-S-Thompson/random- passwords](https://github.com/Keith-S-Thompson/random-passwords)

Of course this won't work for sites that restrict the length of a password, or that require special characters.

<comment><USER14> > Why is it terrible?

Ars Technica published an article a few years ago about password crackers, and one of the subjects they interviewed mentioned the XKCD strip in an offhand remark that was flawed and hinted towards what was probably a poor understanding of the subject matter.

Now whenever the XKCD strip is brought up, people who've been shown the article make an appearance and and talk about the scheme being vulnerable while using the phrase "dictionary attack" in a non-specific sort of way.

That's probably what's going on in the GP comment.

[http://arstechnica.com/security/2013/05/how-crackers-make- mi...](http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat- out-of-your-passwords/)

</comment></comment></comment></comment></comment></comment><comment><USER15> > We generate our password from a cryptographically secure random number > generator. ... We found that sometimes (no predictable pattern), we have > interoperability problems between systems.

If there _was_ a predictable pattern, that would be even worse!

<comment><USER16> well, no. a predictable pattern would be "every time the password starts with 0100101 they are not compatible". its not about the number having a pattern

</comment></comment><comment><USER17> It has happened to me that a registration form would not allow characters like '<' which any keyboard will most likely have, while it allowed unicode characters like (ಠ_ಠ)

<comment><USER13> Sounds like a clumsy attempt to guard against HTML injection.

</comment></comment><comment><USER18> It has occurred to me recently that 12 random words from a 2000 word dictionary will give you 132 bits on entropy. More that you will ever need.

There's a number of advantages to this scheme:

\- It's easy to write down and put in a safe.

\- No funny characters required.

\- Not case-sensitive.

\- If a user makes a spelling error, we can correct it for him without any compromise in security.

\- Guaranteed to be free from offensive words, unlike a randomly generated password.

\- People are using words anyways, misspelled if necessary, whether we like it or not.

We can also make it even more user-friendly by carefully degrading security, such as trying common word substitutions for the forgetful users, or doing some kind of middle-ground "remember me" that does not let you straight in, but only demands first three words (to keep the family members at bay). Like I said, this required careful calculations as to how much security is sacrificed when we do that.

<comment><USER19> This was made clear many moons ago by the now famous xkcd strip [https://www.xkcd.com/936/](https://www.xkcd.com/936/)

<comment><USER18> My innovation :) is to prevent users from selecting their own words, so that we can actually guarantee the entropy required. Otherwise a Markov chain will tear it to pieces.

<comment><USER20> You mean like Diceware[1], which has been around since at least 2000?

[1] [http://world.std.com/~reinhold/diceware.html](http://world.std.com/~reinhold/diceware.html)

<comment><USER18> Good stuff. All we need now is to marry it with a password manager so that it generates random passwords based on this one passphrase and then autofills the web forms for you.

</comment></comment></comment></comment></comment><comment><USER21> The article mentions that hex encoding solves most of the problems but isn't very space efficient. A good alternative may be base64k encoding, which was proposed here on hacker news[0].

This gives you safe strings as well as space-efficient encoding. As a bonus virtually all systems support unicode without any tweaking necessary.

I hope the author of base64k gets around to writing an RFC because it would be a great standard to use.

[0] [https://www.npmjs.com/package/base65536](https://www.npmjs.com/package/base65536)

</comment><comment><USER19> All of these systems suffer from the differing password restrictions imposed by the various services you need to register for.

• Some services require both upper and loweracase characters.

• Some services require punctuation characters whilst others prohibit them.

• Some services prohibit repeated characters.

• Some services impose a minimum password length; some impose a maximum password length; some impose both.

Covering all these situations is nearly impossible.

<comment><USER5> The first line of the article makes it clear this is for passwords used in _programmatic use_.

These restrictions exist for when humans are allowed to generate passwords. This article is discussing systems where humans don't generate passwords and don't in regular operation enter them.

Think of automatic password generation for a secure API endpoint, or automatic generation of private keys secured by a password that typically will be used in a system with it on the keychain but where the backup copies will be stored offsite.

In that case it's acceptable to have a password which is both secure but it has to be easy to type when required but doesn't have to be easy to type (i.e. short) for regular use.

The internet of things means that more and more devices will be creating "users" which are actually just other IoT devices. Those devices/device-users require these sorts of passwords.

</comment></comment><comment><USER22> By just looking at the title and before reading the article, I though they meant that they are checking for illegal strings that are illegal to transmit. [https://en.wikipedia.org/wiki/Illegal_number](https://en.wikipedia.org/wiki/Illegal_number)

</comment><comment><USER23> Throw in the complexity requirements a Windows domain imposes on the password, and this turns into even more of a headache. Of course you can just append A1! to an otherwise sufficiently complex password to meet the requirements, but it will make people freak out in the code review.

</comment><comment><USER24> Ascii85 is a great compromise between binary and base64, which works well for passwords.

</comment><comment><USER25> Another solution is to treat every password as binary. Text works. UUIDs work. Everything works. But folks went down the text-password road a long time ago, so we're stuck with this for now.

<comment><USER26> Passwords-based systems assume input, and most UI frameworks use text strings for inputs.

Binary password is usually not called a password, it's a _key_.

<comment><USER27> Exactly, so if they are not meant to be input, as the article claims, why are they passwords and not keys? Why they are even checked to be valid unicode strings? I know of no encryption algorithm that cares about key being a valid unicode string. Looks like just laziness in distinguishing which data should be binary and which should be Unicode string.

</comment></comment></comment><comment><USER28> I hope the developers of those sites that insist that passwords must be, let's say, between 6 and 18 characters are reading this.</comment>


In 63 days Trump will inherit mass surveillance from Obama - <AUTHOR> http://unplugthensa.org <comment><USER2> Cracks me up this is presented like "Obama, come on, we know you're a good guy. Pleassssse".

Give me a break... Barack loves extrajudicial powers.

This is the problem with large, powerful governments. Sooner or later, the other guys will have the power.

If you voted for Obama (ESPECIALLY twice) and you're worried about Trump having power over the NSA, I am laughing at you.

<comment><USER3> You do realize the bush administration started this entire thing right? Get your facts right.

[https://www.eff.org/nsa-spying/timeline](https://www.eff.org/nsa- spying/timeline)

<comment><USER4> Nowhere did your parent claim Obama created the surveillance state. Only that he loves taking advantage of it, which is true. For the same reasons he has shown no leniency to Manning or Snowden.

</comment></comment></comment><comment><USER5> It's a rather incoherent message. First, they state:

"Take action to dismantle the NSA"

which shouldn't be too difficult, just revoke the 1952 Presidential Order and defund them from the intelligence budget.

Then:

"The NSA has turned the Internet into a weapon, collecting everything it can. "

OK going steady so far, still on-message. All _n_ -billion people on the Internet are in the dragnet and we're all nodding in agreement.

But then, when they enumerate their actual action-points:

"Delete the data stored on Americans, and demolish the physical infrastructure needed to collect this data. "

So it's not dismantling they actually want but _blunting_. Still want to keep the NSA to spy on those nasty non-persons abroad.

Look I don't have a problem with Americans calling for the NSA to stop spying on Americans, that's your internal problem. But please don't wrap it up in hyperbole about 'dismantling' the NSA if you don't actually mean that.

</comment><comment><USER6> Why would Obama pardon Snowden, it is obvious he is in agreement on the whole "he is a traitor" thing. Also, why is Trump inheriting thing a motivating factor for anyone?

"Oh God! Please give us back the situation where government overreach is back in the hands of career politicians!"

How about you instead focus on petitioning to the new President who might actually be swayed into doing something about it if conservative and liberals come together and push for it. He's a populist, make it the cool thing to do...

<comment><USER7> Because the President-Elect has shown himself to be dangerously autocratic, almost comically (if it wasn't so tragic) unprepared for governance up to and including things known by 8th grade civics students, grudge-holding and vendetta-seeking, not a fan of freedom of the press, again almost comically (if it wasn't so tragic) sensitive to insults and slights, and shows no sense of even understanding, much less respecting, the institutions that we have built to rein in this sort of thing.

Like I get it, I was in the streets during Clinton's terms and during Bush's terms and I strongly opposed the expansion of the shadow surveillance state under Obama.

But pretending that handing it over to Trump is a normal handover to a Republican administration is whistling past the graveyard.

<comment><USER8> Looks like that's what America wants in a leader as he was elected democratically.

Either enact the powers or don't. Assume anyone can become President.

Curious how Trump is "autocratic" and Obama is not. Was Obama not autocratic when he drone-killed US citizens without due process? I'm not even sure what the word means. Obviously the President is entrusted with some powers that are autocratic and some that are checked by the other branches.

</comment></comment></comment><comment><USER9> "A new leader will be elected, they'll flip the switch, say that because of the crisis, because of the dangers that we face in the world - some new and unpredicted threat - we need more authority, we need more power. And there will be nothing the people can do at that point to oppose it. It will be turnkey tyranny." \- Edward Snowden (June 2013)

</comment><comment><USER10> I guess it's only ok when YOUR GUY runs ramshod over the Constitution...

It's really telling about intentions, particularly in view of registries, or lists, where it's perfectly ok to keep a master list of gun purchasers, but not illegal aliens (or apparently, even visa holders). We were told "what's the harm in a list". Looks like we knew what what your intentions were the whole time for the list... Action against those people when possible or politically expedient...

</comment><comment><USER11> I wonder what list we all end up on if we actually fill out and submit anything on the form from the link?

<comment><USER9> Now ask yourself if you want to live the rest of your life asking yourself these questions all the time.

</comment></comment><comment><USER12> And Steve Bannon, the guy who runs Breitbart News, will have access to the take.

</comment><comment><USER13> not if Obama shuts it down and does tell him about it...

<comment><USER14> "Damn it, he took the Lightning cable to transfer the data from the external drive! Can't afford another one of those on a $1 salary."</comment></comment>