SMSSecure – SMS Encryption for Android - <AUTHOR> https://smssecure.org/ <comment><USER2> I didn't mind much that TextSecure removed the SMS feature, since I didn't use it anyway, but I think the removal was badly handled. I'm glad someone is catering to the users who used this feature, it gets more eyes on the code and increases the pressure on the Signal team to do things right.

When TextSecure removed SMS encryption there wasn't a clear warning about it in the what's new message, and as far as I can tell there was no deprecation period or warning to users who had been using it. You'd be sending encrypted messages before the update, and unencrypted messages after. For some reason they didn't link to their blog post[1] in the what's new message. It looks to me like they didn't want people to notice that they were removing a feature.

This lessens my trust in the creators and makes me hesitate to update the app since I don't know if they will change or remove features I do use in the future without warning. Hopefully they'll review their process so they don't scare more people over to SMSSecure.

[1] [https://whispersystems.org/blog/goodbye-encrypted- sms/](https://whispersystems.org/blog/goodbye-encrypted-sms/)

<comment><USER3> If you didn't use the feature, you might have missed it, but we talked about its removal publicly for over a year. We also made many incremental changes over that year in order to phase it out so that it wasn't a sudden removal. We did all of that, despite the fact that it was used by an incredibly tiny fraction of our total install base. The people who used encrypted SMS are very vocal, but the users we're really targeting never even knew it existed.

I think projects like this one are great. I have no idea if the people behind it know what they're doing or can write secure software, but we've always wanted some place where the people who want to import their GPG key, manually select their underlying block cipher, or support WoT style key signatures can go. Projects like these might be a better fit for those users.

<comment><AUTHOR> Can you say which users you're really targeting or point me to where you've said it before? Keep up the good work, man!

<comment><USER4> I don't have a link other than their website[1], but the copy there suggests that the goal is to make encrypted communication ubiquitous by making it easy to use. They are targeting the people who would never get gpg set up due to how much of a PITA it is; the people who don't know the difference between AES and 3DES much less CBC and GCM.

1: [https://whispersystems.org/](https://whispersystems.org/)

</comment></comment></comment></comment><comment><USER5> "Get it on F-Droid" \- that sure is a pleasant change from TextSecure's needless drama.

<comment><USER6> OMG. so much this++ I wonder how they're avoiding using GCM like textsecure was

<comment><USER7> We've removed the need for GCM since SMSSecure only deals with the SMS/MMS functionality.

</comment></comment></comment><comment><USER7> I'm one of the developers of this project. If you have any questions, let me know.

To be clear, this project isn't endorsed in any way by Open Whisper Systems. We forked their codebase pre-v2.7.0 and are integrating upstream commits, but that's it.

The idea isn't to compete with TextSecure, it's to provide the encrypted SMS functionality TextSecure used to (with all it's compromises and drawbacks) for people that push-based messaging isn't an option for.

<comment><USER8> The really hard part about encrypting communications is key distribution and validation (eg: validating that the public key for number 555-1234 actually belongs to Alice).

How did you guys attack this problem?

<comment><USER7> Key distribution isn't really something we're doing. Each user just keeps their own list of verified identities.

We're using the same system we inherited from TextSecure for encrypted SMS: Trust keys implicitly on first use, while encouraging users to verify them out of band.

The verification is handled by providing a screen that has your identity and what you think the recipient's identity is. If the recipient's identity matches what your app says and vice-versa, then you know you're talking to the right person.

Ideally, the verification would be done in-person or via another secure means of communication. Currently you can verify identities by just reading them out, or via QR code.

</comment></comment></comment><comment><USER9> "This is a fork of TextSecure that aims to keep the SMS encryption that TextSecure removed for a variety of reasons."

Reason for the fork: [https://whispersystems.org/blog/goodbye-encrypted- sms/](https://whispersystems.org/blog/goodbye-encrypted-sms/)

<comment><USER10> The underlying reasons are actually pretty sensible.

Signal (as it will be) can't deliver encryption via SMS on iOS due to platform restrictions. Neither can tablets or computers normally send SMS messages. (To say nothing of metadata risks, although TextSecure cannot address that without a decoupling layer, like Tor, and in any case low-latency low-bandwidth mixnet messaging is _very_ hard versus nation-state adversaries with traffic correlation abilities.)

It's also clear that voice and video can't be delivered well or at all by SMS/MMS, and that MMS in particular is a huge pain in the arse.

However, users who have limited/no data plans are up in arms. Whole bunch of 1-star reviews. Clearly quite a few vocal users (not necessarily users in regions you might expect) liked this feature, used it, seemingly needed it. I know that sometimes when travelling even I'm out of data service, but within SMS service.

So it may be that a fork does make semantic sense here. Signal will eventually deliver cross-platform best-in-class secure messaging, group messaging, voice/video/etc - features which cannot be delivered by SMS - and SMSSecure could deliver encrypted SMS messages for users on the Android platform (only).

<comment><AUTHOR> If they intend to be a messaging app then they should stop trying to be the default SMS application. They're just another messaging app.

<comment><USER10> Agreed there: if Signal won't do SMS, they shouldn't be catching SMS intents, or they might get invoked when, for example, there's no data. (Of course, there's scope for disagreement here. SMS and particularly MMS are _horrible_ , but sometimes horrible is all you've got.)

<comment><USER11> Maybe someone should suggest this to the team? They probably did that from the get go, but now no longer need to.

<comment><USER12> They said on Github that they are keeping it for a while, so that users still can receive encrypted SMS from users that haven't updated yet.

<comment><USER13> I believe the GitHub issue is about catching intents by default. In case people were thinking support for using TS as a SMS app was going away, here's an excerpt from the mailing list that says it's not:

>> [whispersystems] Can we remove the SMS feature completely?

>> Since the secure SMS option is removed. To reduce the confusion, can we remove insecure SMS option too?

> <insert thread of disagreements>

> Re: [whispersystems] Can we remove the SMS feature completely?

> Everyone can rest assured, we have no plans to do this. I'm pretty committed > to an integrated messenger.

> \- moxie

(For some reason this Apr 1 message is not in the mailinglist archives. Not sure what's up with that.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> As someone who doesn't follow TextSecure or anything else, how does this work? How do my messages get encrypted, yet the people I'm texting don't need to install anything to read them? What am I missing here.

<comment><USER15> Both parties need to have SMSSecure installed, and a secure session started — a roundtrip of sms to exchange keys, or something (im not an expert so not sure if those are keys, or something else).

Otherwise they will only see a garbage of letters/numbers.

<comment><USER16> That seems like it would turn off some potential users due to the hassle of switching apps.

I'm ignorant of the process, but is there no way to check that the user has installed SMSSecure first and, if not, fall back to sending unencrypted data? (perhaps that could be toggled via a fail open/closed option)

<comment><USER15> You can use SMSSecure as your default messaging app. That way you don't have to switch apps. You can even import your SMS from the default messaging app so that you don't loose your history. Bonus: you can then encrypt those SMS locally, but that's optional.

You can toggle the option to send encrypted sms or not, per contact, so if your contact doesn't support SMSSecure, you just send a regular SMS.

The ability to know who's using SMSSecure is interesting and not currently supported (that I know of)

<comment><USER7> Actually, if you receive a message from someone using SMSSecure, you'll get a prompt asking if you want to upgrade to a secure session. But yes, there is no way to look someone up and check if they're using SMSSecure.

The detection was actually inherited from TextSecure and works by "tagging" shorter messages with some detectable whitespace after the message contents. A bit of a hack, but it's a limitation of the transport.

Relevant commit: [https://github.com/SMSSecure/SMSSecure/commit/93d94f2b7a9fd6...](https://github.com/SMSSecure/SMSSecure/commit/93d94f2b7a9fd60c5051e2e3845e40bb857cc5ef)

<comment><AUTHOR> So, that detection can be used by anyone who receives one of my texts to see if I use SMSSecure or not? Isn't that a metadata leak?

<comment><USER7> Yes, anyone who analyzes the messages you send can assume that you are using SMSSecure.

However, compared to the amount of metadata that's already being leaked over SMS[1], adding the fact that you _could_ [2] be using a specific SMS client that has the ability to encrypt messages doesn't seem too bad.

There was an option in a previous version of TextSecure to disable this tagging, but it was deemed unused and axed[3]. For the same reason, I'm loathe to add it back in, but having the option shoved under the "Advanced" menu may not be too bad.

[1] This is something that TextSecure does much better with. SMS messages (even encrypted) still leak metadata on who you're messaging and when.

[2] There's some element of deniability with whitespace tags (granted, not a lot). On the other hand, if you're registered with TextSecure (which can be checked simply by adding a user your contacts and opening the app), there's only one reason you would be there.

[3] See [https://github.com/WhisperSystems/TextSecure/commit/40eca5e0...](https://github.com/WhisperSystems/TextSecure/commit/40eca5e0f600f0579c8e4001da74d19b8785e820)

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Last year I have started to use BABEL.

[https://play.google.com/store/apps/details?id=cz.oksystem.sm...](https://play.google.com/store/apps/details?id=cz.oksystem.sms&hl=en)

<comment><USER11> I don't see a link to github anywhere in the description. Is it open source?

<comment><USER18> I don't know anything about this app and don't know if it is open source (it doesn't look like it is).

However, did you know that not all open source stuff is on github???

<comment><USER11> > However, did you know that not all open source stuff is on github???

Yes, I did. I also looked for bitbucket, gitlab, Google Code, etc. and found nothing.

So I just opened it in JD GUI and saw this gem.

        Cipher localCipher = Cipher.getInstance("AES/ECB/NoPadding");

Don't use BABEL. It's written by people who don't understand security.

EDIT:

        private static final SecretKey a = new SecretKeySpec(
          new byte[]
          {
            -91, 63, 7, 80, 88, -58, -47, -28, 55, 126, -126, 27, 67, -64,
            97, -46, 5, 44, -14, -94, -103, 96, -57, 33, -108, -104, -122,
            125, 49, 29, -25, -27
          },
          "AES"
        );

Is dat a static key? :O

<comment><USER18> > Yes, I did. I also looked for bitbucket, gitlab, Google Code, etc. and found > nothing.

No worries then.

I checked out their website - I can't see any links to source code. So in my opinion it's just yet another closed source pretending to be secure messaging service then...

</comment></comment></comment></comment></comment><comment><USER19> Is this a full replacement for TS or does it just do SMS?

<comment><AUTHOR> It just does SMS.

<comment><USER20> perfect! that's all I wanted it to do anyway.</comment></comment></comment>


Show HN: vim-hackernews - <AUTHOR> https://github.com/ryanss/vim-hackernews

<comment><USER3> Well, it certainly looks better than the current Hacker News design.

<comment><USER4> Really? How so?

</comment></comment><comment><USER5> The Emacs community embraced vim through evil-mode, the vim community is now implementing the rest of the OS.

<comment><USER6> I'd love to have _M-x hackernews_ for wasting time.

<comment><USER7> Ah, uhm... as someone who has m-x TIMEWASTERDUJOUR for a while, be careful :)

</comment></comment></comment><comment><USER8> I didn't play with the HN API but I wonder if it's possible to post comments using the API. I haven't seen any program support user comments, it would be neat to be able to post comments using vim :-)

<comment><AUTHOR> Hi, plugin author here.

It's not currently possible to post comments using the official API (or any of the unofficial APIs), but this probably wouldn't be difficult to implement using a standard POST request to the actual Hacker News web server. The harder part would be getting the interface for posting comments inside of Vim user friendly; it would probably be similar to how fugitive.vim lets you enter git commit messages.

I will definitely look into adding this to the plugin if enough interest is shown.

<comment><USER9> I implemented ajax comment posting for the HNES Chrome Extension, which is open source. It's a dirty hack but it works. Check out the source:

[https://github.com/etcet/hnes](https://github.com/etcet/hnes)

</comment></comment></comment><comment><USER10> Pretty awesome! My default browser is Chrome and I have Vimium installed - <USER2> its a really good to be able to press 'O' on a HN link and continue on Chrome with the same navigation (j, k, ..)

Based on the way I read HN, some customization that I would definitely want to do are:

1\. Headline navigation (mapped to 'j') - move cursor to the next headline instead of the next line

2\. <Enter> / O opens the link in browser instead of the HN thread

3\. Opened links get blurred

4\. Quick page reload mapping and Auto reload

But this is purely based on my style of reading HN.

<comment><USER11> I've wanted something similar to that headline navigation in a browser for a long time. Often times when reading blog-style webpages I want to scroll down to the next story (skipping the rest of the currently displayed story). Using page down requires multiple presses and often leaves the next story half on the page. I would like the next heading to be displayed at the top so it's always in the same spot and so it also maximizes the amount of the story that's displayed on the screen.

I don't know how this could be implemented nicely, though, without making it site specific. I'll have to look into vimium to see if I could at least do it for the sites I visit often. If vimium doesn't allow that kind of customization, pentadactyl and vimperator look like other possible options.

</comment></comment><comment><USER12> It will be very useful at work for reading HN and pretending I am working :)

</comment><comment><USER13> I dig your vim theme, can we get some info on that?

<comment><AUTHOR> You can checkout my vim configuration here: [https://github.com/ryanss/vim](https://github.com/ryanss/vim)

It's just a single, well-commented .vimrc file a little over 100 lines long. The main plugins that add to the visual appearance are the jellybean colorscheme and the fancy status line comes from vim-airline.

<comment><USER14> thanks for turning me on to jellybean, what a great scheme. awesome plugin btw!

</comment></comment></comment><comment><USER15> Does anyone think it would be complicated to port it to Sublime Text? I'd like to, but I'm learning to program.

</comment><comment><USER16> This is gonna so reduce my productivity dude.

</comment><comment><USER17> Reading comments in this thread reminds me how talented people are and how much superfluous engery there is in them.

</comment><comment><USER18> Great and very useful plugin. Good job!

</comment><comment><USER19> Super cool stuff!

I also agree with few others here. Adding comments support would be so awesome.

<comment><USER20> Is that possible via HN API? or it has to do HTTP requests in CLI?

<comment><USER19> The author of the plugin mentions in this thread above, it has to be done via sending POST requests directly to the HN endpoints, and also mentions if this gains enough demand, he might implement it.

I am trying to vote up for the comment support.

</comment></comment></comment><comment><USER21> LOL, so cool. I prefer to read HN in a browser though.

</comment><comment><USER22> Fun!

</comment><comment><USER23> Amazing!

</comment><comment><USER24> Ugh! If you want stuff like this then switch to EMACS.</comment>


Americans are wallowing in decline - <AUTHOR> http://www.foreignpolicy.com/articles/2010/09/24/wallowing_in_decline

<comment><USER2> America has the foreign policy and military structure of an imperial power, but lacks a direct mechanism to collect the tribute that historically supported empires. Instead, the system depends on the US possessing relative economic advantage in a free-trade system to create prosperity which can then be taxed, underwriting the enormous military budget. That system has been broken since the late 60s; globalization and radical antitax conservatism eliminated the financial foundation required to maintain such a vast military. In the end, a state that can't pay for its military ceases to have the ability to act as a hegemon.

<comment><USER3> I generally agree with you that there is no direct evidence of "tribute collection." However, if you look at the most recent example of Iraq, we could make the case that the U.S. has placed permanently placed its military in a country with a lot of oil reserves and could assure itself of cheap plentiful supply from not only Iraq but from the region. Putting my conspiracy theory hat on I would say that the Iraq war was not about WMDs but using it as a excuse to go after the oil reserves.

</comment></comment><comment><USER4> Well, I don't think China is living sustainably either. I see it more likely that south america and europe strengthen while the US wanes.

<comment><USER5> No country is perfect, and the US is still in great shape. But I think the basic issue that Americans are fat and entitled is a serious cultural hurdle that we need to get over. People need to put this into perspective that our global dominance and unprecedented prosperity of the last 60 years was basically served up on a platter by the worldwide industrial destruction of WWII. If we can just accept that we are not in fact smarter or better than any other country, and that sooner or later we _will_ have to compete head on with hungrier nations like China and India, and we stop looking for answers with clever accounting and protectionist policies, or burying our heads in the sand and scapegoating illegal immigrants; if we can come to terms with all that culturally, then I think we will be able to stay in better shape than most countries in the world for the foreseeable future, but that's a big if.

</comment></comment><comment><USER6> "United States deployed force .... has done so in support of "worthy causes all over the planet," whether stopping genocide or promoting democracy in the Middle East.

Was this supposed to be ironic? The US like every other country has deployed force to get what it wants, to stop an enemy or to please it's own voters. Korea, Vietnam, Lebanon, Grenada (in fact most of central america), Cuba, Iraq (1 and 2), Afghanistan (1 and 2) were not about promoting democracy.

<comment><USER7> FYI, Korea is divided into two countries, North Korea and South Korea. I'll leave it as an exercise for the reader to figure out which one is a dynastic totalitarian Stalinist state in which millions of its citizens have starved in the past 20 years, and which one has an ongoing US military presence.

<comment><USER2> South Korea was a often-brutal military dictatorship until the late 1980s. The US was there to stop Communism, not foster democracy. If South Korea is a better place today, it's because of the Koreans themselves far more than the US.

<comment><USER7> > If South Korea is a better place today, it's because of the Koreans > themselves far more than the US.

Agreed. Which makes the inability of the North Koreans to escape from under their repressive regime all the more tragic.

</comment></comment></comment></comment><comment><USER8> Warren Buffett has a good quote saying something like "when people are scared you should be brave and when people are brave you should be scared" and then elaborated by saying something like "It's never as bad, or as good, as people think, it's usually somewhere in the middle." Basically, Buffett says don't believe the hype.

<comment><USER9> The quote is: "Investors should remember that excitement and expenses are their enemies. And if they insist on trying to time their participation in equities, they should try to be fearful when others are greedy and greedy when others are fearful."

<http://en.wikiquote.org/wiki/Warren_Buffett>

<comment><USER8> Yes that's the quote I was thinking of, I think he also said it during a talk with Bill Gates on CNBC during 'Keeping America Great' special: <http://classic.cnbc.com/id/33604479></comment></comment></comment>


A radical business plan for start-ups: Charge people. - <AUTHOR> http://www.slate.com/id/2203436/

<comment><USER2> >Hansson calls this the neighborhood Italian restaurant model of Web commerce: It's a lot easier to start a nice neighborhood restaurant than it is to start the best Italian restaurant in the world (the Google of restaurants). But just like their bigger brothers, neighborhood Italian restaurants make money. Sure, they don't make as much as the best restaurants in the world, but they do well enough—and it's not nearly as much of a headache to run a neighborhood restaurant as it is to run a place where investors, critics, and the world's press are breathing down your neck.

This metaphor is bad. On the internet, there can't really be that many Italian restaurants because there are no local monopolies and no marginal costs.* On the internet, there would only be one Italian restaurant, and it would be 37 signals.

*Sure, there's the speed of light and the cost of electricity, but these are not strongly limiting factors.

<comment><USER3> Isn't this what the 'long tail' is about? Online, your 'neighborhoods' are demographic niches.

Now, if the needs of your online 'neighborhood' have already been met, then that's similar to living in a neighborhood full of Italian immigrants and still looking to start an Italian restaurant nearby. You'll have to move and learn about the needs of other 'neighborhoods'.

<comment><USER4> Many people (including Eric Schmidt in a submission that was posted earlier this week, although I've certainly heard it before) argue that the Internet follows more of a Zipf's Law distribution (<http://en.wikipedia.org/wiki/Zipfs_law>) than a "long tail". In other words, the bulk of the traffic and therefore the revenue is in the head. As a corollary, the Internet doesn't get rid of celebrities, it creates bigger celebrities.

</comment></comment></comment><comment><USER5> I can only speak for myself, but I wouldn't pay for facebook.

<comment><USER6> But would 5% of their users? I could see that.

<comment><USER7> If only 5% of your Facebook network existed, would you use (let alone pay for) Facebook?

<comment><USER8> Typically, there are free tools, and premium tools available to those who pay. They could work on some new features, and only release them to premium users. Ideally, the features are only interesting to those that care a lot about their profile. Analytics are a good option.

They should become a media company though.

<comment><USER9> If they charged people for any custom applications they wanted to put on their profiles, and then gave some of that money to the app developers, I could see both a dramatic decrease in crud, and a dramatic increase in the quality of apps in use (cause, y'know, they're paying for 'em.)

</comment></comment></comment></comment></comment><comment><USER10> I think the Facebook example is a terrible example. If that had been their business model since day one, then fine, they can do whatever they want because every new user knows what they're getting. But if they get huge because users are flocking to their site without having to pay anything and dedicating a lot of time to the site, they shouldn't TAKE AWAY features that were previously free. That just seems wrong to me. That was the model they chose and that's part of the reason why they got so big. I don't think very many people created a Facebook account with the idea that they would eventually have to pay for what is currently free.

If FB had this business model from day one, I highly doubt they'd be as big as they are now. I think it's up to them to figure out a way to make money while not charging for any CURRENT features. If they want to charge for new features, that's fine; otherwise, it's just a bait-and-switch and they're doing a major diservice to the large user base that made them who they are.

</comment><comment><USER11> The moment Facebook does this, I'm starting a Facebook knock-off and stealing every single one of their customers.

<comment><USER12> Then you'd eventually start burning up too much cash, would have to start charging, someone else would clone your facebook clone, and the cycle would start afresh. This is the social network predicament.

<comment><USER13> Yeah, but if I did it, I would sell for a billion dollars. :)

</comment></comment></comment><comment><USER14> Facebook's business model: cross their fingers and hope very, very hard that someone decides to acquire them before the cash runs out.

<comment><USER15> Yahoo already tried.

</comment></comment><comment><USER16> even 37s products embrace free/no-money strategy to some extent

she can charge $ because the products have business use

next, the challenge for 37s is to make a pay-for-use 'wasting-time' sites ... with NO free trial

impossible?</comment>


Medtronic: One ventilators is made up of more than 1,750 parts and 1M LOC - <AUTHOR> https://twitter.com/Medtronic/status/1245777861774118913 <comment><USER2> Sounds impressive to the non-HN crowd, but that's probably 900k lines for an impressive ui, unimplemented libraries, etc.</comment>


Experimenting creation of fake Trend #faketrend - <AUTHOR> http://twitter.com/rohi81 <comment><USER2> Why are you posting your own Twitter profile?</comment>


AI and Tattoos: How We Built a Neural Network for Tattoo Style Recognition - <AUTHOR> https://blog.tattoodo.io/ai-and-tattoos-how-we-built-a-neural-network-for-tattoo-style-recognition-6e641df99a05 <comment><USER2> That's really good!

</comment><comment><USER3> this was really fun project :)</comment>


Angular 1.x Banned from Firefox Addons - <AUTHOR> https://github.com/mozilla/addons-linter/issues/1000 <comment><USER2> Many commenters here seem to be completely misunderstanding the situation.

Browser extensions are really dangerous; if you need to keep your machine secure, you shouldn't use any IMHO. By definition, browser extensions need to be able to access things such as page content. What would stop someone from writing a extension that captures your bank credentials? _Nothing._

Obviously no security-conscious user is going to install a bank credential stealing extension. But what about bugs in extensions? If a buggy extension can be made to execute arbitrary code, it is as dangerous as a malicious extension (if the arbitrary code execution works in the same circumstances).

Angular 1.x basically runs eval on DOM content. That's how it works, it's not a vulnerability in normal use. You make a web page using Angular, and possibly the user has a way to eval arbitrary JS code through Angular, but then they have the developer console so they can run arbitrary code anyway.

With browser extensions it's different. The extension is from one source and runs with one set of privileges, and the page comes from someone else and has less privileges. Now if anything from the page can be eval'd in the extension, that's privilege escalation. Someone creating a site can run malicious content as a browser extension.

It's probably possible to sanitize all external inputs used in the browser extension such that privilege escalation isn't possible, but the Angular team has tried hard with their sandbox solution with no success. Extension developers will hardly do much better, so it makes sense for Mozilla to ban the whole library.

Angular wasn't designed for browser extensions.

WRT the security researcher and Mozilla not disclosing other known sandbox vulnerabilities, that's missing the point (but an interesting discussion in itself).

<comment><USER3> Hey. I work on security for Angular.

> It's probably possible to sanitize all external inputs used in the browser > extension such that privilege escalation isn't possible, but the Angular > team has tried hard with their sandbox solution with no success. Extension > developers will hardly do much better, so it makes sense for Mozilla to ban > the whole library.

AngularJS runs expressions that are in your page's HTML when it initializes (or when you explicitly call angular.bootstrap on an element), but only on the page where it is loaded. If an extension uses Angular within the extension, that's perfectly fine, security wise. Unless the developer explicitly requests it, pages visited cannot move code into an extension's context (which would be dangerous in any case, Angular or not).

Even when the developer explicitly moves data from a web page into the extension context, this does not cause a security issue, even when the data ends up in the DOM. Once loaded, Angular does not revisit the DOM to run expressions in it (otherwise all Angular pages would be compromised). Care has to be taken when using things like ng-bind-html, but the security profile for an extension is the same as a regular web page here. With Angular's $sce service and automatic escaping/sanitizing, it's actually reasonably easy to write safe web applications that properly escape user input.

All of this is unrelated to the expression sandbox. The sandbox was never intended to be a security feature, but rather a feature to keep developers from shooting into their own foot (e.g. by creating global variables). It was considered to be defense-in-depth mechanism for a while, but it turns out it is at best misleading for users who believe it protects them. That is why we removed it.

<comment><USER2> Thanks for the reply. I mistook the sandbox to be related to $sce. It's been a while since I last coded Angular.

So you're saying that Mozilla is mistaken in their decision, and the only way for page content to be eval'd with extension privileges is if the developer was careless with ng-bind-html or $compile?

<comment><USER3> It's a bit more complicated.

Yes, Angular itself is fine, and there's no problem with escaping or eval'ing per se.

However there is a corner condition in which Angular being present in an extension might weaken some security measures. It requires multiple issues to happen together, including the victim page being vulnerable in the first place. I'm actually not sure if that is the issue that Mozilla was thinking about, but it is a problem. We will put some defense in depth into Angular to mitigate this, but I believe it's a general issue with how extensions are handled, not limited to Angular.

Sorry for being a bit vague, but no patch has been released yet.

<comment><USER4> thx for the update

</comment></comment></comment></comment></comment><comment><USER5> Note that the Angular team is working with Mozilla and the researcher on this (see [https://github.com/mozilla/addons- linter/issues/1000#issueco...](https://github.com/mozilla/addons- linter/issues/1000#issuecomment-255183470)) and that NDAs are a real, if insane, thing still to this day, and there is literally no way to legally compel any party to admit to being under NDA except in a court of law.

Should the researcher have told the Angular team? Yes. Should they have told the entire world? Probably no. Should Mozilla tell the world? Probably even less no. As long as the parties are talking (which they are), this is an unfinished security review on lock-down to prevent exploitation in the interrim.

<comment><AUTHOR> > As long as the parties are talking (which they are), this is an unfinished > security review on lock-down to prevent exploitation in the interrim.

I agree! There are a lot of Chrome extensions out there which could be affected. Immediate public disclose would be irresponsible.

<comment><USER6> This "vulnerability" is harder to exploit in Chrome because extensions in Chrome (unlike in Firefox) have their own private DOM, and settings page have isolated DOM too. If an extension uses Angular only with its private DOM there is no vulnerability.

The vulnerability can be exploited only if an extension is running Angular on an untrusted page which is less likely in Chrome (but of course one should not underestimate the level of incompetency of a modern frontend developer).

UPD: @bzbarsky noted that Firefox is using the same security model as Chrome so both browser extensions can be vulnerable. To exploit a vulnerability, several conditions should be met: 1) extension should inject Angular into a web page 2) attacker should be able to find a way to get from content script context into extension's background page context.

<comment><USER7> Chrome has many many extensions which run on and modify the page DOM just like Firefox! I think it might even be reasonable to guess that around half of extensions do this.

<comment><USER6> Modifying DOM is not enough to cause a vulnerability. In Chrome content scripts (the ones that are injected into a page from an extension) have limited privileges though there still can be the ways to exploit them.

<comment><USER7> Chrome content scripts can have permissions to make AJAX requests to any origin. Sure, it's not a straight-ticket to getting code native execution and installing malware on your machine, but it means an exploit against an extension with wide enough permissions could harvest your email and bank info.

</comment></comment></comment></comment></comment></comment><comment><USER8> So, there's so many problems with this i don't know where to begin. Since folks have already noted the "not notifying google" issue, let me point out another:

Prior to banning, i can find literally no discussion or details about this being about to happen (IE no notice), pretty much ever.

You can see it was initially noted here: [https://github.com/mozilla/addons- linter/commit/86f4dfb44355...](https://github.com/mozilla/addons- linter/commit/86f4dfb44355a7de68d87cf72aa678086894dac7)

I can find no discussion around it (maybe it's there but i'm missing it? I looked in a lot of places).

You can see it fixed an issue to "warn third party developers of things we banned/don't advise", but there's nothing about initially banning anything there, and it was added _with an initial ban list containing angular_. I would have expected a page added, then a ban discussed, then a ban added. or something.

In fact, the details of the ban changed ([https://github.com/mozilla/addons- linter/commit/2dcc2226e2ec...](https://github.com/mozilla/addons- linter/commit/2dcc2226e2ec9dea65708b0a1cc97a9cd593d82d)) repeatedly without notice either.

This seems really bad. I would have expected, at the very least, a heads up to extension developers or something or even _a more public notice when it happened_ so that some discussion could be had about it.

Instead, it looks like the only way you would have found out about it is by trying to lint an extension and see it banned (IE after you developed it), or somehow random browsing of doc pages mozilla has.

<comment><USER9> > Instead, it looks like the only way you would have found out about it is by > trying to lint an extension and see it banned (IE after you developed it)

It's one of the big dangers of a "walled garden": you are subject to the whims of the arbiter.

<comment><USER10> I wonder if any business-critical apps stopped working because of this?

</comment></comment></comment><comment><USER11> Using big external libraries in Firefox add-ons used to be totally prohibited. Jquery used to be prohibited outright. It's an undesirable practice. Add-ons operate at a higher privilege level than web pages. The low-quality webcrap that can be tolerated on a web page has no place in a privileged add-on.

<comment><USER12> Agreed and this is why React has been given a pass I think, because it's only for display purposes.

<comment><USER13> Really it doesn't matter if it's for display purposes or not. It all boils down to implementation. I can make a view library riddled with XSS vulns in very little time.

</comment></comment></comment><comment><USER14> So someone found some sort of vulnerability in Angular 1, told _Mozilla_ about it, but told them not to tell the Angular team?

What is going on here?

<comment> TD-Linux It is possible that the researcher also secretly shared the results with Google, but then nothing happened?

<comment><USER15> As claimed in the comments, Angular 1 is now community driven instead of officially supported by Google.

<comment><USER16> Not true. Google has diverged development of Angular 1 and 2. Angular 1 was initially developed with designers in mind, but it caught on with developers. They developed Angular 2 with developers in mind. Angular 2 is different from 1 in many respects. I don't see Google dropping Angular 1 support anytime soon.

</comment></comment></comment></comment><comment><USER17> Bitwarden is a password manager? And their engineer is asking, after being told a hint of serious security issues in their framework, to just forget about it and let them publish?

That's an interesting approach.

<comment><USER18> No, the engineer is asking for more information so that he can determine if the application is truly affected by some unpublished Angular vulnerability or if Mozilla is just being too aggressive with their ban hammer because someone said "Angular 1.x was no longer being officially supported", which is false.

<comment><USER19> I think encoderer was referring to [https://github.com/mozilla/addons- linter/issues/1000#issueco...](https://github.com/mozilla/addons- linter/issues/1000#issuecomment-255096658), where the engineer asks, "Is there any possible way for us to get around this ban?"

<comment><USER20> Followed up immediately with "Are all parts of Angular affected?" The charitable interpretation is that he is asking "is there a safe subset of Angular that we can use instead of a blanket ban?".

<comment><USER17> Yeah that's a fair (and more charitable) way to read that. But it's also not that clear. He spends a lot of time worrying about how much time they've spent on their extension.

Why no "woah, our other angular apps could be affected, is there any safe subset of angular 1?"

There aren't many products where security matters THAT much. I'd hope that the people working on password managers have a total security first mindset.

</comment></comment></comment></comment></comment><comment><USER21> The banned version is the 1.5.8. Could the following announce be related?

Angular 1.6 - Expression Sandbox Removal: [https://angularjs.blogspot.mx/2016/09/angular-16-expression-...](https://angularjs.blogspot.mx/2016/09/angular-16-expression- sandbox-removal.html)

<comment><USER22> removing the sandbox just removes the illusion of being protected.

<comment> vladimir-y Correct, now it should be clear for all that Angular v1 is dangerous thing by design and it should not be used at all. Most likely a lot of not very experienced developers do for example $watch on value provided by the user input and that's a 100% XSS vulnerability since $watch does evaluate value if that was a string. And $watch is just a one example, there is a list of methods that do expressions evaluation.

<comment><USER23> Note that in the context of a browser extension an "XSS vulnerability" means "a web page just got to run code with the extension's privileges"....

[Disclaimer: I work for Mozilla.]

<comment> vladimir-y I guess extension's privileges means more privileges than a regular web page has (accessing file system for example?), if so then it's even more dramatic.

<comment><USER23> Right. Extensions have more privileges than normal web pages.

For the specific case here (webextensions), the extension asks for a list of permissions at install time, so which privileges it has, exactly, depends on the extension. [https://developer.chrome.com/extensions/declare_permissions](https://developer.chrome.com/extensions/declare_permissions) has documentation on what the various permissions you can request are.

</comment></comment></comment></comment></comment></comment><comment><USER24> Ugh, this kind of thing gets my blood boiling. It was clearly said that _a security researcher_ disallowed Mozilla from reporting the vulnerability forward. It's the individual to blame, not Mozilla.

In any case Personally I wouldn't want to run a large priviledged application as a browser extension when it's interacting with random webpages AND handling my security credentials. Too much attack surface.

<comment><USER25> Curious, do you use a password wallet/manager application, and if so how do you get passwords out of it and into the browser? I'd like to know if there's a better solution. (I use a browser extension.)

<comment><USER26> I think his point is that running the entire Angular 1.x framework to power a browser extension gives a large attack surface.

<comment><USER24> Yes. And to answer nchelluri's question: Auto-typing, though I believe that's available only on desktop operating systems.

<comment><USER27> > though I believe that's available only on desktop operating systems.

And on Android (where you set up the password manager as a custom keyboard), and possibly an iPhone

</comment></comment></comment></comment></comment><comment><USER28> > My information is that Google stopped supporting angular 1.x months ago. It > is now a community driven project.

I totally missed this - was there a notice of this posted somewhere?

<comment><USER22> Yeah that doesn't sound true at all.

<comment><USER29> Was recently at an angular conference -- they said they would continue to support it until the _majority_ of the community had made the switch. That's so far from happening, I imagine they'll be supporting it for years.

<comment><USER30> At least until they get tired and change their minds, which may not take that long.

<comment><USER31> Even if that did, there might be a community that pops up to take on the burden instead of G.

</comment></comment></comment></comment></comment><comment><USER32> I'm not sure if this is the same case, but I assume it is: if you're wondering why the researcher doesn't want to share the vuln listen to this talk: [https://www.youtube.com/watch?v=U4e0Remq1WQ](https://www.youtube.com/watch?v=U4e0Remq1WQ)

Roughly at 41:30 he explains why he doesn't want to disclose the vuln. The tl;dr is he thinks the sandbox is broken beyond repair and whatever fix they come up he can create another bypass for the sandbox. But he doesn't want to do this all the time and he needs his vuln as a poc to show to customers if they abuse the sandbox.

<comment><USER33> That was a good talk. I highly recommend watching the entire video.

</comment></comment><comment><USER34> That doesn't make much sense. If there's a vulnerability in Angular, doesn't it mean that there's a vulnerability in the JS engine that runs the Firefox addons? And in that case, can't an attacker replicates whatever Angular is doing to make an exploit? Basically it sounds like it's something for Mozilla to fix, not the Angular team.

<comment><USER35> Exactly. If you can write a vulnerability in Angular, you can write it in vanilla Javascript as well. Unless Angular is using `eval()` or something and Firefox bans any use of `eval()`, which is reasonable...

<comment><USER23> > Unless Angular is using `eval()`

Which it is, as far as I can see, though it tried to make it slightly safer ... until version 1.6, when it gave up on pretending it's at all safe. The linked slide share from the github issue talks about this a bit. See [http://www.slideshare.net/x00mario/an-abusive- relationship-w...](http://www.slideshare.net/x00mario/an-abusive-relationship- with-angularjs) slides 16-31 which talk about the sandbox angular tried to apply to the environment it did the eval() in, but in the end it's grabbing text from the DOM and doing an eval().

Note that in a browser extension doing text from the DOM (controlled by the web page) and doing an eval (with the privileges of the extension!) is obviously really really bad.

[Disclaimer: I work for Mozilla and I'm not an expert on Angular.]

</comment></comment></comment><comment> angry-hacker Can someone explain me:

If angular can do it, so can just plain javascript? Then it's a problem with their extension architecture?

As much as I hate bundling big libraries everywhere, why ban angular?

Also, is it possible the researcher wants to get money from Google and didn't want the vulnerability to be shared?

<comment><USER7> Yes, you can write vulnerable code in plain javascript:

        eval(document.querySelector('.foo').textContent);

In a regular web page where you don't allow the user to insert arbitrary HTML, it's a perfectly fine line allowing you to store code in the DOM.

If you do that in a browser extension where the DOM is controlled by the web page, then you've got a big security vulnerability: the webpage can put anything it wants into a foo tag and then your extension will execute it with its privileges! Your extension will be taken down from the Firefox Addons Marketplace if it's reviewed and this line is found running. If lots of extensions added this line, then Mozilla would probably automate blocking extensions from containing it.

Angular 1.x does something like this line. It's perfectly fine in web pages where you control the DOM, but is insecure if the DOM comes from an untrusted outsider!

<comment> angry-hacker Why doesn't Firefox simply disallow eval? You would get an error in console explaining and that's it.

<comment><USER36> Lots of perfectly sensible JavaScript code uses eval for things like feature detection and runtime code generation. If you removed eval they'd just use 'new Function' instead, which has most of the same problems.

</comment></comment></comment></comment><comment> yc-kraln "we were not able to report them to angular as the security researcher who found them asked us to not share them."

Nice.

<comment><USER37> I read that and said a literal WTF. How is it at all acceptable to honor such a request? What possible good reason could there be?

Unless the discloser was the US Government and the request was actually a court order. But this seems ludicrous. If they require secrecy around the exploit, they wouldn't have disclosed it to Mozilla at all.

<comment><USER38> Mozilla is probably unable to disclose not just the vulnerability, but other surrounding info they may have been provided, including which other parties have received that info. They are not saying the Angular team is unaware of the problem, right? Only that they themselves are not the ones reporting it.

If you don't honor such request without a VERY STRONG reason, nobody in their right mind will ever disclose anything to you ever again. Right now we don't and can't know if such a strong reason exists.

<comment><USER37> "They are not saying the Angular team is unaware of the problem, right?"

Are we just going to assume the folks at Mozilla are clairvoyants? How would they know what the Angular team knows? If it's known in general that the Angular team knows about this issue already, perhaps through other means, then the statement that they haven't disclosed this to the Angular team makes no sense. The statement is, "Mozilla is choosing to do it's part to keep Angular in the dark about this."

<comment><USER5> Well, there's [https://github.com/mozilla/addons- linter/issues/1000#issueco...](https://github.com/mozilla/addons- linter/issues/1000#issuecomment-255183470) ...

<comment><USER38> And now one of the researcher has commented [https://github.com/mozilla/addons- linter/issues/1000#issueco...](https://github.com/mozilla/addons- linter/issues/1000#issuecomment-256183820)

</comment></comment></comment></comment></comment></comment><comment><USER39> What is justifying this?

If the vulnerable part is in Angular, there's a 100% chance that someone can write code in plain JS that is vulnerable to the same attack. E.g. if there was something in the hashbang-url-router that would lead to eval'ing the code in the hash (which I just made up, but would describe such a class of vulnerability). This means it's pointless to ban Angular.

If something Angular does triggers an issue in the Firefox JS engine, it is Firefox that should be fixed, instead of allowing essentially a 0day exploit to be alive.

<comment><USER40> > If the vulnerable part is in Angular, there's a 100% chance that someone can > write code in plain JS that is vulnerable to the same attack.

"can", not "will". If _everything_ that uses Angular is vulnerable (unlikely? I couldn't say), why would you not ban it? This is along the lines of "If Heartbleed is in OpenSSL, there's a 100% chance that someone can write code in plain C that is vulnerable to the same attack". Yeah, they can, and it happens all the time, but why not fix a known hole?

> E.g. if there was something in the hashbang-url-router that would lead to > eval'ing the code in the hash (which I just made up, but would describe such > a class of vulnerability). This means it's pointless to ban Angular.

This would be an excellent reason to ban Angular since a huge majority* of extensions never use eval().

* If this isn't true… I don't want to be in web dev anymore.

</comment></comment><comment><USER41> Let me make sure I understand this. This vulnerability is basically because the addon authors are using angular to parse webpages, and therefore because they don't have control over the DOM elements angular is being used on, they're vulnerable to all the xss escapes in [0], right?

Because as far as I can tell, all of the escapes in [0] require the attacker to write to the DOM being evaluated by the angular engine. Normally this isn't a big deal, because the developer controls the DOM. In more pedestrian situations, if you've got a wiki, cms, forum, or other situation where untrusted people are creating content, you can't give those content creators the ability to write to parts of the DOM where an xss abuse might happen, and if you do it is pretty much your fault anyway (angular isn't really to blame here, because if you're letting users write to the DOM directly you've got trust issues).

The mozilla situation is particularly problematic because the mozilla addon runs its javascript context in some elvated privilege mode, and normally that javascript just manipulates the DOM directly to generate addon-specific UI (like password fill helpers, for example). But because that angular is being run on a DOM outside of the control of the addon authors, it's also subject to all kinds of XSS escapes.

I get that, it's fair. Seems like, though, this isn't really an angularjs issue specifically. It feels like this is a broad problem with the security model for browser addons. Like: replace angular with some other view library that you rolled yourself and it could still have all kinds of issues.

Basically anything that uses the DOM to store state (instead of a one-way state -> dom transformation) is subject to manipulation by malicious DOM injections, be they from forum posters or creators of pages that will be visited by plugin users. So, again: I see why angular1 has issues here. But this is a much bigger security hole, honestly. I don't think the javascript runtime for plugins should expose anything to the js running on the page, but that's a lot more complicated, since the plugin runtime is almost always really interested in spidering the page DOM and altering it by responding to the state of that DOM.

0:[http://www.slideshare.net/x00mario/an-abusive- relationship-w...](http://www.slideshare.net/x00mario/an-abusive-relationship- with-angularjs)

<comment><USER7> >I don't think the javascript runtime for plugins should expose anything to the js running on the page, but that's a lot more complicated, since the plugin runtime is almost always really interested in spidering the page DOM and altering it by responding to the state of that DOM.

Firefox/Chrome/Safari extensions already run in an "isolated world" so that they have separate sets of global variables and DOM-wrappers, so that javascript values never leak directly and modifications to globals don't affect other worlds. However, they all see and manipulate the same content in the DOM. I'm unsure if you're proposing anything different from the current situation.

</comment></comment><comment><USER18> Angular and Firefox teams are working to resolve the issue. The issue is not related to sandbox ... see [https://github.com/mozilla/addons- linter/issues/1000#issueco...](https://github.com/mozilla/addons- linter/issues/1000#issuecomment-255269186)

</comment><comment><USER42> If there is some permutation of JavaScript statements (library or otherwise) that displays a security vulnerability for the user, isn't that the browser's fault and not the application's? And isn't library detection just a hacky substitute for an actual fix of said fault?

<comment><USER7> It's not the browser's fault if an extension has a vulnerability which gives away the capabilities the extension was given. It would be the browser's fault if the extension had a vulnerability which somehow managed to give away more permissions than the extension was given in the first place.

In this specific case, Angular runs eval-like functions on HTML in the DOM. The DOM can be controlled by the webpage. If Angular is running in a higher- privilege extension, then the webpage can put code in the DOM and let Angular execute it from within the extension. This seems to be a fundamental part of Angular 1.x's design. It just isn't built for this use case.

<comment><USER42> That makes sense, thanks.

</comment></comment></comment><comment><AUTHOR> I am really worried about the security implications for addons like bitwarden, if mozilla is right about this. I hope that competent people will take a close look.

</comment><comment><USER43> Isn't any "vulnerability" in a JS framework a vulnerability in the browser's own handling of securing it? Like, there is nothing angular is doing that someone else couldn't do, intentionally, to create said issue, right? Wouldn't the correct handling of this to be to secure the damned interpreter thats running the code to prevent it from having the effect they are trying to mitigate?

This feels like a lazy shifting of blame

<comment><USER7> Angular evals text stored in the DOM. If you alone are in control of the DOM (like in a normal webpage), there's no issue. If someone else is in control of the DOM (you're running Angular in a higher-privileged extension running on a random webpage's DOM), then they can put code into the DOM which then gets picked up by Angular and executed within the extension with the extension's full permissions. This isn't an issue inherent to the language or browser at all. This is an issue just comes from that Angular 1.x is designed for use- cases where the DOM is trusted, and that's not the case for browser extensions.

<comment><USER43> But thats not special to angular... right? You can write that in vanilla javascript just the same - the issue is that the script running in the extension is given the ability to do that. They dont seem to be blocking a feature in javascript, they seem to be blocking a lib that uses it. Angular can't do ANYTHING that any other bit of javascript can't do in the same context.

Angular is just JS, its not special JS, its just JS. If angular can do something, it can be done without angular so blocking angular does nothing to prevent the vulnerability.

<comment><USER7> Eval has legitimate uses, and there's plenty of ways that extensions can be insecure or malicious without using eval.

Firefox's Addons Marketplace reviews extensions and rejects ones that are malicious or insecure.

The issue is not that Angular uses an inherent insecure feature. The issue is that Angular does insecure things: it lets a webpage run any code with the extension's privileges. If the extension has privileges to your email domain, then the webpage can abuse the extension's privileges to harvest your email. An extension that let your email be harvested would get rejected regardless of whether it used eval or not. (For example, a malicious extension could be made which doesn't use eval and is just a couple hard-coded lines to make privileged AJAX connections to gmail.com. There's no technical features that the extension is using that shouldn't be available.)

</comment></comment></comment></comment><comment><USER44> If they had let this through and people got owned because of it people would be screaming at Mozilla. Damned if they do...

</comment><comment><USER45> Uhm, wait what? Firefox extensions can execute literal code from visited a website? To me that sounds like the root cause of the problem and a glaring security hole - either the website has to be sanitized/projected into a harmless dom abstraction or extensions shouldn't be able to use any kind of dynamic evals.

Sure angular may be vulnerable by default but good luck thinking that all other extensions out there are safe and not using evals at any point.

<comment><USER7> >either the website has to be sanitized/projected into a harmless dom abstraction

Should Firefox contain code to recognize text that looks like Angular templates and then break it somehow? That'd be extremely specific.

Eval isn't an inherently unsafe feature, and it doesn't have a monopoly on insecurity: Angular doesn't even require eval. It can run without eval in a CSP-supporting mode that's equally vulnerable.

</comment></comment><comment><USER46> Angular 1.x is still quite being actively developed and it will be many years before it will become unsupported. I'm sure if they report the vulnerability it would be fixed instantly seeing the amount of activity on github.

<comment><USER7> The issue is a fundamental part of Angular 1.x's design. It runs eval on text within the page DOM. This isn't secure within extensions where the page DOM is controlled by the webpage, and Angular is running within a higher-privileged extension.

<comment><USER46> > Angular is running within a higher-privileged extension.

Ok, thanks for the explanation. I've developed chrome extensions before but firefox very long time back, so my knowledge is rusty, but please tell me 2 things:

1\. Say hypothetically if AngularJs can do it, doesn't that mean any Javascript can do it too? I mean Javasript contained within the extension code?

2\. In chrome extensions we use "ng-csp", otherwise it won't run. Is this addressing the same thing in chrome and if so, why can't it do it in firefox?

<comment><USER7> >1\. Say hypothetically if AngularJs can do it, doesn't that mean any Javascript can do it too? I mean Javasript contained within the extension code?

Angular doesn't have a monopoly on insecure code! Anyone can write insecure or malicious code. Firefox's Addons Marketplace will reject an insecure extension just the same when they notice anything amiss whether it uses Angular or not.

>2\. In chrome extensions we use "ng-csp", otherwise it won't run. Is this addressing the same thing in chrome and if so, why can't it do it in firefox?

Chrome enforces a CSP directive that prohibits eval in UI pages. This is unrelated to Angular being insecure to use in extension content scripts. (When I've said a few times that Angular is insecure because it "evals content from the DOM", I'm not trying to be specific to the `eval` function. I think its CSP fallback is just as insecure.) Angular 1.x is bad news in Chrome content scripts just the same.

</comment></comment></comment></comment><comment><USER47> That suddenly makes Angular look scary for some clients. vulnerability that is known to an entity/entities but unknown to the Angular developers or contributors....

<comment><USER6> The vulnerability occurs only if you inject Angular into a web page from browser extension in some browsers. There is no vulnerability if you are writing a SPA using Angular.

</comment></comment><comment><USER48> Why not use Google Caja instead of a separate sandbox?

<comment><USER40> Overkill for what was never intended to be a sandbox for untrusted code. The "sandboxing", like Django templates', Jinja, Nunjucks, etc. is a well-intended measure to keep logic out of templates, but in practice only really gets in the way and causes mistaken assumptions about security.

</comment></comment><comment><USER26> Title should by "Angular 1.x Banned from Firefox Addons"

<comment><USER49> Thank you, we've updated the title from "Angular 1.x Ban".

</comment></comment><comment><USER50> Thats some solid hate right there. Not expected from Mozilla at all!

</comment><comment><USER51> Nice extension marketing

</comment><comment><USER52> This thing makes me believe that we should not use any OSS project which released by a big companies such as Google and Microsoft. Even if they don't say that they're dropping support, when they start to work on another project, it won't be a community-driven project and slowly die.</comment>


Oily Speculations - <AUTHOR> http://www.newyorker.com/talk/financial/2008/07/07/080707ta_talk_surowiecki/

<comment><USER2> What really stuck out to me was how pleasant it was to read a news story about oil that wasn't alarmist. I kept waiting for the "Burn the witches!" segment that never came.

</comment><comment><USER3> Wouldn't speculators "punish" themselves if their price expectations were unwarranted (= big losses for speculators)? What logic could lead to laws to curb speculation?

<comment><USER4> Yes. Futures speculation is a zero sum game. There's a loser for every winner, so blaming speculators for price movements in the spot market is absurd. What about the speculators who have lost? Spot prices are well above the delivery price of most maturing futures contracts.

If politicians want to pillory traders and suppliers the charge should be keeping prices too low in prior years and being foolishly shortsighted. The price should have risen much higher much sooner to encourage conservation and inventory. Current market conditions should have been more broadly foreseen and the increase should have been more gradual and sooner. Current prices are clearly justified by supply and demand, future expectations thereof, monetary policy, and geopolitical concerns.</comment></comment>


Desperate tech investors turn to virtual meetings in Fortnite to find deals - alex-wallish https://www.telegraph.co.uk/technology/2020/03/23/desperate-tech-investors-turn-virtual-meetings-fortnite-find/ <comment><AUTHOR> If thats the case, I can't take any of these VCs seriously. Not even a Google Hangouts or a Skype call, but this looks like it is straight out of @VCBrags.

If they're so 'desperate' that they turn to this, then they might as well raise the capital using Bitcoin or virtual Fortnite coins and watch both of their investments sink or swim.

Good luck to them, because this is the start of a golden age of creating the perfect exit-scam.

<comment> alex-wallish Why does playing Fortnite prevent you from taking someone seriously?</comment></comment>


Top Albums of 2016: METACRITIC - <AUTHOR> http://www.metacritic.com/browse/albums/score/metascore/year/filtered?sort=desc <comment><USER2> The critical roundup is often more useful (as some of the more obscure albums in this list just don't get enough reviews to render the average meaningful): [http://www.metacritic.com/feature/critics-pick- top-10-best-a...](http://www.metacritic.com/feature/critics-pick-top-10-best- albums-of-2016)

A down year for music (though it unfortunately seems like I've been saying that for the last 4 years). I've listened to everything in the top 20 in the critical list, and the only albums I'll likely be listening to in 2017 and beyond are the Radiohead and Bon Iver entries. Certainly tracks here and there I loved from Beyonce, Kanye, Anderson .Paak, Chance, and Frank, etc, but none of the other albums have grabbed me yet from start to finish. (That can always change, of course!)</comment>


I built 100 Projects in 100 Days – here is my overview - <AUTHOR> https://www.florin-pop.com/blog/built-100-projects-in-100-days <comment><USER2> That's quite impressive! I imagine creating daily projects also alleviates the stage fright developers have for showing off personal projects.</comment>


Container House - <AUTHOR> http://www.treehugger.com/tiny-houses/shipping-container-house-designed-move.html <comment><USER2> _It should be noted that this is not a standard container that you can pick up really cheaply; it is a full-side access box designed for extra-large machinery. They have reinforced roofs and a side wall made of doors, which is more costly than a solid wall of corrugated steel; There are not a lot of used ones hanging around; the best price I could find online for one was about US$ 4,000._

That's probably without delivery, and it's a used container without thermal insulation or a good unused volume in which to place it. Generally the theory of shipping container houses, which has been hot for more than twenty years, is not born out as practical desirable solutions. I mean if you're hiring a boat builder to fit out your living space, starting with something other than a shipping container is likely to yield a higher level of livability.

</comment><comment><USER3> Awesome. I love the fact that it can still be shipped.

</comment><comment><USER3> Awesome! Great that it can still be shipped.</comment>