What's wrong with in-browser cryptography? - <AUTHOR> http://tonyarcieri.com/whats-wrong-with-webcrypto <comment><USER2> I think it's obvious to everyone that code coming directly from the server can not be trusted completely by the end user. The only solution that might work is signed browser extensions. I really would have liked to learn about more considerations when taking this route.

<comment><USER3> However code coming from the server can be verified, so you can know if the cryto.js delivered to you was modified from a known good version. You can audit a particular version and say, "this works correctly", and then look at changes over time.

For instance you can have a greasemonkey script that tells you when the crypto code is different from last time.

The best solution realistically would be SSL _plus_ encrypting data first in the browser (separately encrypt the data and the transmission of it).

<comment><USER4> sorry, this is only somewhat related. but i am really ignorant. this is a genuine question that i have for quite some time now.

when i download security relevant software, the website usually gives me a hash/signature of the download file, so i can verify afterwards whether the data i downloaded really is the file i want or whether it has been tampered with.

but in case an attacker switches the downloaded file for a malignant one, why should s/he be so stupid and not also switch the hash/signature on the website? i am positive i am missing something, as really smart people [0] are doing this, but i do not get it. thanks in advance.

[0] [https://www.torproject.org/projects/torbrowser.html.en](https://www.torproject.org/projects/torbrowser.html.en)

<comment><USER5> The signature is generated using public key cryptography [1] meaning, to generate a valid signature, you have to have the private key.

Because the signature only has to be generated when a new version of the file is released, you can use the most bothersome (and effective) manual methods of security, like keeping the private key on an air gapped [2] computer.

So if an attacker manages to switch the downloaded file for a malicious one, they may still not have got access to the private key used for release signing.

Of course, the attacker could still remove all links to the signature file and all mention of it in the public documentation, so downloaders wouldn't know there was a signature to check. So it's better if the site isn't compromised in the first place.

[1] [https://en.wikipedia.org/wiki/Public- key_cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) [2] [https://en.wikipedia.org/wiki/Air_gap_%28networking%29](https://en.wikipedia.org/wiki/Air_gap_%28networking%29)

<comment><USER6> So this will also probably be another seemingly clueless question, but after reading up on air gapped computers, how would that help with the new hash?

</comment></comment></comment></comment></comment><comment><USER7> The big problem with most (all?) in-browser cryptography is you still need to trust the server. If you have to trust the server what is the value of doing crypto on the client side. You may as well do crypto on the server side and communicate between the server and the client using SSL.

<comment><USER8> You pretty much have the same issue with any desktop software - you have to trust the authors and the server that gives you the download files (or the server(s) that give you checksums and public keys to verify the download).

Doing in-browser crypto requires less trust than server-side crypto. With in- browser crypto, the server would have to do an active attack and serve malicious scripts, which could be detected. When everything happens in the server all the time, it would be a passive attack that doesn't require any client-side modification and could easily go undetected.

Also, with open-source websites, people could audit the source code and ensure it works as advertised. Combined with a browser extension that verifies the source code from the website matches the code on the public code repository, this could make it much easier to trust websites to do in-browser crypto right.

</comment></comment><comment><USER9> I have a problem that is best solved by encrypting data in the browser - because the server should not be trusted with seeing the information in the clear.

This is much like the exception the OP mentions at LivingSocial. Can anyone weigh in on whether that's safe?

<comment><USER10> Safe(r) than just sending it in the clear so the server can read it, probably. However, if your server gets compromised, the JS code doing the crypto can easily be replaced to just return the results plaintext...in which case you're still doing SSL, so good job, but the CC#s are vulnerable to whomever wishes to sniff them on the server, which is pretty much how most online systems work anyway.

Couldn't hurt to use asymmetric encryption using the provider's public key, but just beware that without packaging/signing the crypto code, it's a tossup whether or not it's actually there.

Edit: if it's absolutely imperative that the server not be able to read the message, then not packaging _all_ the code is _unsafe_. However, if the server not being able to read the message is nice to have but non-essential, then by all means, run your code in a webapp.

<comment><USER9> Thanks. I'd use a browser extension, and also constrain what gets sent to the server.

If the server was really compromised, it could just copy the CC# into another field in the form (so it gets sent twice, encrypted and unencrypted) - and the server would get the data without having to change the JS. Integrity checks would not turn anything up. A properly paranoid browser extension should have a specified format for sending a form, so that no extra information is leaked.

In my case it's bids rather than CC#s, though the same pattern holds of encrypting with the tender creator's public key.

</comment></comment></comment><comment><USER11> If you were to install some packages on a system, would you install unsigned ones that are allowed to modify every other package, altering how other programs work, without confirmation? That's effectively the state of browser security right now.

We must stop living in this fantasy playground of pretending no security in the browser is acceptable, because important things like passwords, PIN numbers and credit card numbers pass through it.

An ability to sign (not hashes, _signed_ ) and verify JS, CSS and HTML would be a start. Once verified, a security policy* is applied further sandboxing an app so it doesn't go to shit with modifications or inappropriate introspections by injected or malicious code (while usually retaining normal things like the browser and plugins). Also reasonable limits to mark objects and parts of the DOM as only available to certain objects, not Orwellian mandates to throw webdev into chaos.

This is something that would take a great deal of coordination with reluctant vendors that see change as cost, but it would be the biggest win for browser security.

* Something a bazillion times easier to use than SELinux.

<comment><USER12> > An ability to sign (not hashes, signed) and verify JS, CSS and HTML would be > a start.

This apparently exists, although I've never managed to get it to work myself: [http://www-archive.mozilla.org/projects/security/components/...](http://www- archive.mozilla.org/projects/security/components/signed-scripts.html)

</comment></comment><comment><USER10> Sensible post. Yes, doing crypto in the browser is generally harder due to not having direct access to OpenSSL and due to XSS and many other javascript- related vulnerabilities. But if you cover your ass, don't eval code willy- nilly, and package _everything_ into a browser extension (not just your public key or 90% of your JS, but _everything_ ) you can mitigate a lot of potential threats. Also, don't try to reinvent SSL. If you do your own crypto in the browser, it should be for peer to peer, not peer to server.

With something like Firefox, you're kind of screwed. For instance, if I open firebug while using my Turtl extension, I can read the contents of memory right there...there's no real separation/sandboxing between extensions. If one extension can read the contents of another, you've got problems. Chrome does this better.

The best way is to package everything into a separate (os-level) app.

<comment><USER13> >The best way is to package everything into a separate (os-level) app.

I agree with this on the premise of threats like XSS, however there is a human aspect of security which might be overlooked. The problem with apps is that everything that is a website today will become a native app tomorrow. App developers might claim that their app is more secure than using a website to do the same thing, because of the included native crypto implementation. Users might then associate any native app with having greater security than a website accessed through a browser (which may not necessarily be true.) Users might become further desensitized to installing everything from the internet as an app.

Why is this a problem? Websites normally cannot access things like your personal files, without you explicitly choosing a file from your computer using a file dialog, whereas if you run a native app with your user credentials, it is immediately able to access any file that you have permission to access, without necessarily informing you.

Perhaps OS-level security and sandboxing is going to have to improve for this sort of thing to be a good option.

<comment><USER10> I can see this side of it as well. I tend to come from the camp that if you don't release your code as open-source, you can't _really_ call yourself secure. If you're 100% open-source, distributing a desktop/mobile app will have enough transparency to determine "is it going to steal my CC numbers?"

There's also a barrier to entry to get a user to install anything. Mobile is different, but in the desktop world, if I told my users to download the "CNN desktop app!" they'd roll their eyes because why would anyone install some trashy malware-ridden program when they can just look at the website, for free, and as you put it, much safer? From my perspective, the only reason to distribute a "secure" desktop app version of your webapp is _if you don 't have a webapp to begin with because it's not secure to do so_. So the desktop app would be an open-source complement to the browser extensions your secure app uses.

<comment><USER13> The products where users seem to preferentially install native apps are services like Dropbox, or video games, where there is value added by not using the "website version." Something that would be very revealing is to investigate how secure these kinds of apps are today. I find it unlikely that in the near future, native app security practices will change very much.

</comment></comment></comment></comment><comment><USER8> With Bitrated, I'm trying to resolve the main issue he's raising by creating a browser extension that verifies all the content served from the webserver is properly digitally signed and that it matches the source code repository on GitHub.

("Browser extension" at [https://www.bitrated.com/security.html](https://www.bitrated.com/security.html))

This two-factor verification helps protect against attacks, both by a third party attacker and by the service operator itself.

</comment><comment><USER14> Anyone interested in working on a man-in-the-middle resistant version of browser/Javascript encryption? I have the basic idea described here: [http://www.research.rutgers.edu/~ashwink/ajaxcrypt/index.htm...](http://www.research.rutgers.edu/~ashwink/ajaxcrypt/index.html) I have working code, but it needs some refactoring.

</comment><comment><USER15> I have this feeling that one day we'll look back in a sort of amused horror that people used to let their browsers run code they downloaded from unknown servers. But I'm not really sure what we'll be doing instead of that.

<comment><USER16> You can rather easily make a verified kernel that executes foreign code safely. The trick is in also making it fast and featured.

<comment><USER17> IMO, this is really important and system application security is not in much better shape than web browser security; you still need to trust a huge number of sources and these sources have known security issues regularly. For that matter, it is probably not that difficult to insert known vulnerable code into some widely used application without it being detected. While there will always need to be some trusted code, it is possible to limit the amount of trusted code and the number of sources that code comes from given better OS security models.

Since hardware and firmware can also be subverted, IMO a new security model should also be able to track and limit what network traffic is intended so that the network traffic actually generated can be (potentially) verified by additional machines on the network and/or by other verifier virtual machines on the same system.

</comment></comment></comment><comment><USER18> Could Dart or other languages in the browser solve this problem of not being able to do crypto properly in the browser, or is this a more fundamental problem of having crypto inside a browser in the first place?

<comment><USER19> The fundamental issue is that the code needs be audited and signed offline so it can't be changed. Unsigned code should not be run. This makes releases harder (no push on commit).

It's not language-specific. App stores already work this way (including the Chrome web store), so a deployment mechanism is there; it's just not used as often as it should be.

It's funny, back in the day we debated ActiveX (code signing) versus sandboxes (Java and JavaScript) and the real answer is that you should have both (as Android does).

But code signing isn't magic either. You still need someone to do the auditing, and users to be careful about what they run. Since users are so trusting, I'm not sure that app stores in practice are any more secure.

<comment><USER20> How does this differ from HTTPS? Since we're dealing with World Wide Web, it can't be that you would have to install the public key of _every_ site that you visit to get signed versions of the code – it would make browsing infeasible.

It just boils down to the CA based system that is already employed by HTTPS. You must of course trust the other party and their systems, but that's the exact same with code signing. To identify the other party, code signing uses a pre-shared secret (e.g. your OS comes pre-installed with their public key). In HTTPS you identify the other party by them possessing the right certificate, that's signed by a trusted intermediary. There's no really better way to do it, bar quantum crypto and HTTPS+DNSSEC, which is sadly not widely supported.

<comment><USER19> The difference is that if a server running HTTPS is hacked, the attacker can modify the JavaScript at will. With an app that's signed offline, this isn't possible; you could even redistribute it on an untrusted mirror.

Also, in theory, an independent auditor could rebuild the app from source and verify that the bits match, and do an independent audit of the source. So signed apps are more verifiable.

The trusted base for a signed app is (browser + app + app signer), not (browser + app + server), where the server might be a virtual machine in the cloud and you need to trust the virtual machine host provider too.

This doesn't matter most of the time because you have to trust the server anyway, but in the case of someone wanting to encrypt something on the client that cannot be decrypted on the server, it does matter. Encrypting on the client is mostly pointless unless the client code is independent of the server, which requires it to be independently signed.

There is still a cert chain of course, but it's a different one where the developer's private key doesn't get uploaded to the server.

Signed apps are fundamentally not how the web works. The argument here is that the web is basically broken for client-side encryption and the app store model is better for things like secure email or a bitcoin wallet.

But since most app store apps aren't open source and the open source ones aren't independently audited in practice, it's not clear it's a practical difference.

</comment></comment></comment></comment><comment><USER21> I think the OP makes some good points, but I dislike when people are put off of working on their own crypto. Can crypto be difficult to implement? Certainly. Is it impossible? No. The OP makes it sound like properly implementing and authenticating a block cipher is way too difficult for the average programmer, when it is really rather trivial.

<comment><USER22> For those who can't read sarcasm over the internet, he's kidding. Go ahead, implement ECB mode, what could go wrong, LOL. I've also got a really nice "special" RNG for you too, although its really slow it is NSA approved.

If you only need security theater just stick to ROT-13.

As a tiny little sub area of computational activity, writing crypto is total sorcerers apprentice territory.</comment></comment>


GitLab 7.8 release - <AUTHOR> https://about.gitlab.com/2015/02/22/gitlab-7-8-released/ <comment><USER2> GitLab CEO here, we're very excited that we just enabled free use of git-annex on GitLab.com. We think it is the best solution to version control large files when Dropbox doesn't cut it anymore. What do other people use for large file versioning?

<comment><USER3> We haven't found a solution as we have given ourselves requirements to store revisions of large binary files (PSDs), but we don't have the ability to effectively manage 8GB repos (and I don't know whether anyone does.)

It seems like ultimately, versioning software will need to grow to understand more file types than text in order to keep track of changes to many large files. I imagine Git plugins available by filetype and perhaps automatically sourced by Gitlab when needed, but I know that would be an enormous task.

Unrelated: can you possibly work with Atlassian to get Gitlab integration for SourceTree? It would be very convenient for us. :)

<comment><USER2> Versioning large files is hard. The way to do it is not to put them in the git repository itself but to manage symlinks to the SHA-1 of the large file in git. This way your git repo stays under 1GB but you can request the file from a server. GitLab EE uses the open source Git Annex for this but adds code to check your project permissions. All you need to do to get the files is a git clone and 'git annex sync --content'. Read more about this on [https://about.gitlab.com/2015/02/17/gitlab-annex-solves- the-...](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem- of-versioning-large-binaries-with-git/) Please let me know if you have any other questions.

We would love to see better support for GitLab in SourceTree and so would many others [https://answers.atlassian.com/questions/47020/comments/26160...](https://answers.atlassian.com/questions/47020/comments/2616044) The response from Atlassian in that thread indicates they are less inclined to do it. Since GitLab is an open source alternative for their Stash+JIRA+Confluence+Bamboo products I understand their stance on this. Of course it never hurts to ask in that thread.

<comment><USER4> ... actually, versioning large files is easy, but not directly in git.

[https://github.com/bup/bup](https://github.com/bup/bup) strategically breaks files to chunks of ~8k length, in a way that makes small changes to a big file become a small change to a small number of chunks (ideally, changing one byte in a 80GB file would change exactly one such 8KB chunk -- and that is often the case, though it's common than 3 or 4 would change).

bup then puts[0] the chunks into git, together with a "reconstruction map". As a result, you can efficiently put huge files in git and only pay for the real deltas in storage.

[0] It doesn't actually use git or libgit - it writes git packs directly.

<comment><USER2> Also see the discussion about Bup 3 days ago: [https://news.ycombinator.com/item?id=9074114](https://news.ycombinator.com/item?id=9074114)

I really like git annex since the repository is still completely git compatible.

</comment></comment></comment></comment></comment><comment><USER5> I recently found out GitLab is a one-click install inside your self-hosted sandstorm.io server.

<comment><USER2> Yes, thanks to David Renshaw from Sandstorm for the integration. It also is a one-click install on Google Cloud Compute and Digital Ocean.

<comment><USER6> I used this on Digital Ocean and it's been up for months without an issue. Not sure how to go about upgrading, I might not

<comment><USER7> GitLab CTO here. You can easily update your GitLab at Digital Ocean because it uses omnibus package. We recommend updating GitLab for performance updates, security updates and new features. Please use this guide for update [https://gitlab.com/gitlab-org/omnibus- gitlab/blob/master/doc...](https://gitlab.com/gitlab-org/omnibus- gitlab/blob/master/doc/update.md)

</comment></comment></comment></comment><comment><USER8> I have migrated yesterday from 7.3 to 7.8 and all went smoothly, I really appreciate the migration guide and especially the "what to do if things go south" which is always my biggest concern.

My only little problem is that now the list of merge request display the assignee instead of the creator. It does not really make sense to me as there's already the filter "assigned to me". It breaks a little my workflow because I do code reviewing for a dozen of person across several project, and when they tell me on skype "pushed" , now i need to ask them "errrr which MR number?"

<comment><USER2> Glad to hear your upgrade went OK. I made the change to show the assignee. We think it is more important to show what has to be done than to show what has been done. But I agree that for your use case it might be a small step back. What about filtering the MR's by author as you can do on [https://gitlab.com/gitlab-com/www-gitlab- com/merge_requests](https://gitlab.com/gitlab-com/www-gitlab- com/merge_requests) ?

<comment><USER8> I understand the logic, but however it does not stand to the fact that on the homepage when I click on MR I already see a filtered version of "only those assigned to me" , which in that case make the display of the assignee redundant, and I hardly specifically go on the project page then on MR.

EDIT: I would have nothing against a middle ground of displaying both.

thanks for your quick feedback.

<comment><USER2> It makes sense that if you go to [https://gitlab.com/dashboard/merge_requests?assignee_id=1](https://gitlab.com/dashboard/merge_requests?assignee_id=1) it shows the author instead of the assignee. Same for other places where you filter on assignee. Feel free to create a merge request for this. We can't display both since it will look messy.

<comment><USER8> yes your solution of displaying author when assignee is already filtered.

I don't know ruby at all, but I guess I can try, as you're the one who made the change to put assignee instead of author, I would not be against some guidance on where to look for the modification :)

<comment><USER2> You can find it here [https://gitlab.com/gitlab-org/gitlab- ce/blob/master/app/view...](https://gitlab.com/gitlab-org/gitlab- ce/blob/master/app/views/projects/merge_requests/_merge_request.html.haml#L27)

<comment><USER8> thank you, I'm a bit confused by the code (the fact I know nothing about ruby, let alone rails, without talking about haml may be part of it)

in my naive understanding, in order to implement the feature as you said, it would require from the controller to send to the view a variable "isFilteredByAssignee"

How can one find the corresponding controller, I've tried grepping for _merge_request.html.haml or just _merge_request without finding anything.

I guess the index.html.haml in the folder do something magic to render the list of merge_request with the @merge_requests ?

<comment><USER2> I just discussed this with some other team-members. The consensus is that changing what information is displayed is confusing. We don't have a lot of space to work but but we can add 'by' and an avatar. So go from:

#337 assigned to Sytse Sijbrandij => #337 by AVATAR assigned to AVATAR Sytse Sijbrandij

When you hover over the avatar it should show the name of the author in a tooltip.

If you don't feel comfortable making this please make it into a feature request on [http://feedback.gitlab.com/forums/176466-general](http://feedback.gitlab.com/forums/176466-general)

<comment><USER8> ok, perfect thanks, I will try and if I don't get something quickly i will open a feature request.

Thanks again for the time you took to answer me

<comment><USER2> Thank you for contributing by raising this an looking into it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I dont quite understand the GitLab model.And why GitLab.com is free.

Shouldn't GitLab.com cost something, and its revenue will be used to support the hosting as well as building a sustainable business model? The idea is for those who want to own their data or the fear of vendor lock in they could use the Community version.

The current offering looks like those Free Webhosting long time ago that offers unlimited bandwidth and webspace.

<comment><USER2> Thanks for asking ksec. GitLab has an open core model. The open source GitLab Community Edition has an MIT license. GitLab Enterprise Edition contains extra features and you have to get a subscription to use it. The most common subscription costs $50 per user per year. You can find more about the feature difference on [https://about.gitlab.com/features/#compare](https://about.gitlab.com/features/#compare)

We think that repository hosting will be like email hosting. Most people will have an account for free with only forum support (similar to gmail and outlook.com). For the next few years we expect the on-premises subscriptions to bring in more than enough money to pay for hosting. Because code hosting is a central hub for many services we think that long term revenue model will be a marketplace for additional services.

Please let me know if you have any questions.

<comment><USER10> Ah, proprietary addons. I've always wondered would selling AGPL exceptions work? I thought it did for gitorious.

<comment><USER2> If you don't distribute the product you don't have to share your contributions if I understand the AGPL correctly. Most users of GitLab use it internally and never distribute the code outside of the organization. If they do so they will share the source code anyway since almost all of it is written in interpreted languages like Ruby.

</comment></comment></comment></comment><comment><USER11> I've been using GitLab since version 5.0. When we decided to start using GitLab - it didn't have a lot of needed features and we found ways to live without them, but with time they added them and added more useful features which we enjoy and use daily. You're doing great work, guys!

<comment><USER7> GitLab CTO here, thank you for using GitLab. We are happy you enjoy it!

</comment></comment><comment><USER12> I have been wanting to self-host GitLab for quite some time, but it doesn't support the workflow my team uses on Bitbucket.

We have a team and by default all the members of the team have read access to all the team repositories (unless overridden at a repo level) and write access to the repositories they created or forked. Developers can create forks within the team namespace and send pull requests between themselves and to the official "blessed" repo from which releases are done. Those with write access to some repositories can commit to those repos and also merge pull requests. Admin can basically do everything within the team namespace.

That said, congratulations on keeping GitLab rolling forward with more and more features and bugfixes every release.

Edit: Fixed a typo and added some more detail.

</comment><comment><USER13> The annex thing is interesting. For anyone looking for an alternative, try providing a version within a file's URL and retrieving it in your build script, ie. _wget_ [https://internal-server.youco.com/path/to/v3/big- file.psd](https://internal-server.youco.com/path/to/v3/big-file.psd)

Internally, you can create the _/ path/to/v3/_ part using either a snapshot- capable filesystem with periodic snaps (in which case _v3_ might become a datetime string in _yyyymmdd_ type format) or a script that creates incrementing version numbers of symlinks to the same when filesystem contents change -- using _inotify()_ or similar.

<comment><USER14> This is precisely what I'm about to do; I'm surprised something doesn't already exist for this.

</comment></comment><comment><USER15> I can't sing the praises of Gitlab loud enough - we (Infoxchange) started using Gitlab and Gitlab-CI around 8 months ago or so and haven't thought twice about our decision.

It's a really solid project using great technology that's easy to support and use!

<comment><AUTHOR> That's awesome to hear.

It's great to have a community of people using and building GitLab, that contributes new features, critizes decisions and helps everyone else stay sharp.

</comment></comment><comment><USER16> My company runs Gitlab in-house, and we've integrated it with Redmine and Slack. It works great. Thanks Gitlab!

<comment><USER2> GitLab CEO here, thanks for using GitLab and you're welcome!

</comment></comment><comment><USER17> Gitlab is great but I wish the CI SaaS providers would get their act together and support it. Most only support Github and (at a push) Bitbucket.

I suppose though, if you are running your own Git repos then you probably want to run your own CI.

<comment><USER18> GitLab Developer here, have you tried GitLab CI [https://about.gitlab.com/gitlab-ci/](https://about.gitlab.com/gitlab-ci/)? It's not as feature packed as some of the SaaS providers' offerings, but it does the job, runs on your own server, is fully integrated with GitLab.

<comment><USER2> Thanks Douwe. If people want a CI Saas they can also use Magnum CI that supports GitLab or ci.gitlab.com. The latter is completely free, even for private projects, as long as you bring your own runner to execute the tests.

</comment></comment></comment><comment><USER19> Do you have any plans for a windows installer?

The alternative to Gitlab that I've found on windows are a bit lacking. Bonobo is nice but very basic.

<comment><AUTHOR> At this point, no. GitLab runs very well on Unix machines and is easy to install. It is literally three commands and doesn't require some arcane unix magic to setup and keep running.

Starting a VM is easier than ever nowadays and installing GitLab no harder.

I'm so comfortable saying this, that if you have any problems getting it setup, email me at job [at] gitlab dot com and I'll help you get rolling.

<comment><USER20> As an addendum to that, I was able to get a basic Gitlab up and running with Docker in a very short order on Windows. Might be worth recommending: [https://github.com/sameersbn/docker- gitlab](https://github.com/sameersbn/docker-gitlab)

<comment><USER2> Great to hear that! In general we recommend using the Omnibus packages [https://about.gitlab.com/downloads/](https://about.gitlab.com/downloads/) but other installation options (including Sameer's image) can be found on [https://about.gitlab.com/installation/](https://about.gitlab.com/installation/)</comment></comment></comment></comment>


Few buyers at Ocean Tomo high-tech auction - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/03/28/BU8116O74L.DTL <comment><USER2> This seems like the perfect event to hold online. Everyone wants to remain anonymous to the point that the "most serious bidders made bids by phone" while the rest "stay in their hotel rooms and have representatives in the audience who send them text messages."

I don't see who the fancy location is intended to impress. It sounds as though all the "serious bidders" are just going to be inconvenienced by it.</comment>


Project Triforce: Run AFL on Everything - <AUTHOR> https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/ <comment><USER2> What's AFL? "american fuzzy lop" / [http://lcamtuf.coredump.cx/afl/](http://lcamtuf.coredump.cx/afl/)

</comment><comment><USER3> I really wanted this to be about Australian Rules Football...

</comment><comment><USER4> I really want AFL to be able to run on arbitrary VMs (specifically, I want to run AFL on my rails application).

Are there plans to add pluggable tracing modules to AFL?

<comment><AUTHOR> checkout the details of the project, the idea is that you can run AFL on arbitrary VMs (like your rails VM)! just need to have your test cases, your userland harness, and the addresses to monitor for "panics"

<comment><USER4> AFL can fuzz ruby by running ruby on arbitrary inputs. This tests that paths through the ruby interpreter are being stressed.

AFL cannot fuzz ruby _code_ using the same mechanism, because it does not have the right level of insight. AFL can't detect if a branch in my ruby code was tested, only that the code for `if` in the core ruby interpreter has been tested both ways. For this reason, in order to properly test interpreted code, you need to add the AFL instrumentation at the ruby layer, not the native layer.

I don't think AFL currently supports this, and I don't think this project actually enables it. But I would be happy to be corrected!

<comment><USER5> > AFL can fuzz ruby by running ruby on arbitrary inputs.

If you're brave (consider "system rm -rf /home") this is worth doing. I recently ran such a fuzzing test against GNU Awk.

Unfortunately the bugs I reported are still unfixed, but it didn't take too long to find them, and it was a good learning exercise:

[https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=816271](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=816271)

[https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=816277](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=816277)

I'm sure passing "random" input to Perl, Python, Ruby, and many other languages will lead to similar results.

<comment><AUTHOR> i've actually used AFL to find some input parsing bugs in Perl, Python, and Ruby.

Perl was the team who fixed them the fastest.

none of the teams (rightly) considered these particularly high impact.

</comment></comment></comment></comment></comment><comment><USER6> [https://web.archive.org/web/20160627201122/https://www.nccgr...](https://web.archive.org/web/20160627201122/https://www.nccgroup.trust/us/about- us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/)

</comment><comment><USER7> So I am still reading through their Linux container security paper, and I like their stuff, but who are these NCC people? In the last few months I have seen multiple postings on their papers and blog posts, seemingly out of nowhere, never having heard of them pry to the container paper.

<comment> dyn- Glad to hear it. As mytummyhertz said, NCC Group (where we both work) is made up in the US from iSEC Partners, Matasano Security and Intrepidus Group consultancies (who were all purchased by NCC Group in the last few years). In the UK it's primarily NGS. iSEC Partners/Matasano/Intrepidus Group/NGS have published research/security presentations/tools (sslyze) etc for years.

<comment><USER7> I am kind of new to the infosec scene. I was curious because your stuff seems thorough, but the new TLD domain made me wonder where you all came from, like rebranding or something else. Sounds like a little column A, little column B.

My favorite quick security tool on Linux is firejail, which uses seccomp-bpf under the hood. So I was quite excited to see in your container paper discussion of that and the interaction of Linux subsystems I do not really grok.

Keep up the good work. Obviously not all for me, but I benefit. :-)

<comment> dyn- Thanks, firejail is a nice little tool. Yeah the .trust TLD isn't a rebranding or anything, just another NCC Group side-project.</comment></comment></comment></comment>


Ask HN: Anyone getting repeated RoboCalls from Google+? - <AUTHOR> I get them at least 3x per month..for the last 5months.<p>tl;dr "It is extremely urgent that you complete your profile ..." <comment><USER2> They're not from Google+. really. it's spammers/marketers.</comment>


Building a browser extension? Be careful not to XSS the whole internet - <AUTHOR> http://blog.tinfoilsecurity.com/building-a-browser-extension-be-careful-not-t-17787

<comment><USER2> There's been a lot of research about this recently (I've brought this up on HN previously). A team from Berkeley broke 50% of the 50 most popular extensions last year [1]. Some other researchers looked at explicitly malicious extensions [2].

One thing the authors don't mention (wich is brought up in the first paper): things can be much worse than this. If you inject untrusted content to the innerHTML of the extension itself, you've given an attacker the full privileges and permissions of the entire extension. This can be very serious if the extension has access to lots of data (e.g., many Chrome extensions have arbitrary access to all http and https webapges -- a bug in one of your extensions could give an attacker XSS on a user's bank).

The Google team has taken steps to mitigate this [3]. If you write a Chrome extension, you're being negligent if you don't implement a strong CSP. That will prevent the previous issue entirely, but not the issue brought up by OP.

[1] [http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities...](http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities.pdf)

[2] <http://profsandhu.com/zhang/pub/ndss12-chrome.pdf>

[3] [http://blog.chromium.org/2012/02/more-secure-extensions- by-d...](http://blog.chromium.org/2012/02/more-secure-extensions-by- default.html)

<comment><USER3> > That will prevent the previous issue entirely, but not the issue brought up > by OP.

Hmm, shouldn't even a normal CSP prevent the issue brought up by the OP? I haven't actually written a CSPed extension, so I may be missing a key problem, but my understanding is that no inline scripts will execute (only scripts from whitelisted domains), which would prevent an injection like that.

<comment><USER2> You would think that it would. But the way Chrome has implemented CSP, it doesn't. When you specify a CSP in a Chrome extension, it applies to the core extension (the background page) and all content scripts. It does not, however, apply to webpages you are running on.

So, if your CSP is set to deny all images, you can still add an image to a webpage. You just can't add an image to the core extension itself. Similarly, if you block eval() with a CSP, you can still eval() from the context of a webpage.

<comment><USER3> Ah, yeah, thanks :)

It seems like it would be difficult for the browser to prevent extensions from ever suffering from that kind of attack. "any script tag that wasn't there before this function call is not executable" isn't too bad of a start, but even a moderately complicated web app likely has places where you can inject content that will be operated on by javascript from the site itself, which _then_ transforms it into an XSS attack. For example, many sites will sanitize any user input, but will trust the content of dom elements created by themselves, without thinking about the case where the contents have been replaced by an extension which hasn't been properly sanitizing its own output.

It should still be covered by any CSP that a site has enabled, though. That (and this article) is a good argument for everyone to strongly consider adding a CSP to their sites, so that inline scripts can't be executed, even if an otherwise well-meaning extension slips up.

</comment></comment></comment></comment><comment><USER4> The most important thing in this article, which should be H1 bold at the top, is:

 _If you didn't create the data, assume it is malicious_

<comment><AUTHOR> Completely agreed. Updated. Thx for the feedback.

<comment><USER4> Awesome! This right here is the best example of social media in action -- a suggestion for improvement was made, and the author liked it and implemented it.

<comment><USER5> This is not social media in action, this is HN in action :-) browsing comments here is more tolerable for authors and makers than practically anywhere else on the internet (basically because the discussion is _better_ ), hence why getting feedback here is more likely to happen.

<comment><USER4> I'll agree that the conversation here tends to be better, but there are still pockets of reddit that have the same high quality and have the same potential for authors. It is always made me happy when this type of interaction would happen.

</comment></comment></comment></comment></comment><comment><USER6> Interesting.

It would nice if Chrome separated 'DOM write' permissions from 'DOM read' permissions. AFAIK, today extensions can't request only 'read' permissions.

Yes, I understand that it's a pain for new Chrome developers to have to understand the permission system among other things. I liked the easy ACLs of Chrome when I started.

So maybe they could allow permissions to be written in two different ways in the manifest file? Today's quick-and-dirty coarse-grain permission system would co-exist with a fine-grain permission system that would use new directives.

I'd love to prove to my users that my extension is in fact not malicious.

<comment><USER7> > Yes, I understand that it's a pain for new Chrome developers to have to > understand the permission system among other things. I liked the easy ACLs > of Chrome when I started.

That's a good thing IMO. Anyone who doesn't understand permissions and how to handle them, shouldn't be able to release anything in any app store.

<comment><USER6> You probably knew this, but you can write and distribute Chrome extensions without having to upload them to the chrome app^Wweb store.

Second, I've tried to work twice with Doing-It-Right (i.e., fine-grain) permission systems. Once with apparmor and earlier with SE Linux. With AppArmor, I wanted to set up rules to prevent Skype from reading any except a couple of directories. The sheer number of permissions I had to configure was exhausting and I gave up. Maybe I missed something simple, but that's why I'm not clamoring for the current simple, but coarse-grain permission system to be abandoned.

<comment><USER7> Well yes, grown-over-time permission systems are also at fault when it comes to the lack of security in third party extensions/apps. IMO unix is still the standard in terms of simplicity and power of permissions - if the system architect separates concerns correctly into different base entities ('files'), the permission system just falls into place. You know what other system did this pretty much perfectly? Lotus Notes. Yes, I'm serious - it's a document based DBMS with per-document permissions where everything is a document, including the application design, contacts, logs, calendar entries. Too bad its UI is still stuck in the early 90ies.

</comment></comment></comment></comment><comment><USER8> Mozilla has a submission process for Firefox extensions wherein the extension is manually reviewed by a Mozilla developer before being allowed in the add-on marketplace. I know from experience that extensions with XSS vulnerabilities fail inspection and are not hosted in the market until the code is fixed.

As far as I can tell, Chrome lets you upload pretty much whatever you want into the Chrome webstore.

I'd be curious whether Firefox extensions have these issues in even close to the same proportions as Chrome extensions.</comment>


That mystery Go player crushing the world's best online? It was AlphaGo again - <AUTHOR> http://arstechnica.com/information-technology/2017/01/alphago-is-back-and-secretly-crushing-the-worlds-best-human-players/ <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=13320013](https://news.ycombinator.com/item?id=13320013)</comment>


Airbnb.com: Necessity Begets Creativity - <AUTHOR> http://the99percent.com/articles/6920/Airbnbcom-Necessity-Begets-Creativity

<comment><USER2> This article is from September of 2010.

<comment><USER3> I never understand why people don't put dates on things. I compulsively date everything I create. Not doing so only leads to confusion, as demonstrated by the more recent comments on the article. A lot has happened with Airbnb since it was written. And then there's "the 99%" having another prominent meaning today, which might confuse people unfamiliar with Behance. Dates and context are a usability feature!</comment></comment>


No Way to Build an Operating System - <AUTHOR> http://weblogs.jupiterresearch.com/analysts/card/archives/2008/05/no_way_to_build_1.html

<comment><USER2> The article hinges strongly on this quote, which strikes me as wrong:

 _Windows 7 will ship in 2009, almost certainly in time for holiday PCs. Microsoft disclosed today that there would be no major architectural changes from Vista, which would greatly reduce development complications._

The author probably heard "Vista applications will be able to run on their original architecture" and reported it as "Windows 7 will have the same architecture as Vista."

Noises coming from Microsoft suggest Windows 7 will support "legacy" applications using virtualization so that they can run in their native environments, specifically to set Windows 7 free to do things without the strain of backwards compatibility. Much like Apple when it released OS X.

One thing to remember though, Windows 7 is just vapourware and a couple of videos so far.

</comment><comment><USER3> Another link-bait, trashy, speculative article 3 years too early trashing Microsoft and Windows 7.

I'd expect this from some random blogger but not Jupiter Research.

I'd rather them focus on trashing Vista than spreading this garbage.

Did I mention Windows 7 is 3 years away?

</comment><comment><USER4> So let me get this straight: WinFS never happened, and MS engineers drooled over spotlight, therefore multitouch won't kill Google.

Like walking through NYC, and telling the guy picking cans out of the garbage that he'll never get the Mona Lisa into the Met that way.

<comment><USER5> I think the point he is trying to make is that Microsoft has failed to create anything innovative, or even follow through with their plans to implement things other people have done, and will be unable to compete with a company able to do both such as Google.

</comment></comment><comment><USER6> It all depends on your perspective. I found the article very interesting. Take it as what it is: anecdotal at best.</comment>


Chief Tries to Infuse Yahoo With a Start-Up's Spirit - <AUTHOR> http://www.nytimes.com/2013/04/08/technology/chief-tries-to-infuse-yahoo-with-a-start-ups-spirit.html?pagewanted=all&_r=0

<comment><USER2> I really hate that the headline references "a Start-Up's Spirit" when they recently did just about the most technologically and culturally backwards move possible. This is the kind of move that a nimble startup would reject and a slow-moving and backwards big company would embrace.

The article cites Yahoo's desire to attempt to compete with top companies for prime talent. Yet they're throwing away the chance on hiring top remote developers and relying on such innovative workforce management techniques as "your butt better physically be in this chair from 9 to 5."

<comment><USER3> Most startups that I respect side with Meyer on this issue of colocated teams. There's much room for disagreement or, to put it positively, experimentation here. But there's no basis at all for acting like this is settled and anyone who disagrees with you is "backwards".

In threads about this, I feel like a lot of HNers who want to work remotely have been very vocal, acting like there's a consensus among anybody smart when in fact exactly the opposite is the case, and to some extent crowding out substantive discussion. Personally, I agree with Marissa. I want my team in the same location and preferably the same room. It makes a huge difference to the quality of collaboration and discussion. If what you're trying to do doesn't depend so much on collaboration, then fine, but what I'm trying to do does.

<comment><USER4> I for one care less about working remotely than about being forced to work in a noisy, distracting open space environment. (Or, for that matter, in offices having no sound insulation, which can be as bad if not worse.)

Consistently, I've found that the people who like such environments tend to be the ones creating superficial solutions full of errors and short-sightedness.

Group dynamics subsequently spread the fallout from such shortcomings. (I've come to think of corporations principally as a mechanism for risk dilution, in this respect.) But, for those who find this insufficient, the process is exhausting.

It goes further than that, for me. I simply _can't think_ in the midst of the noise.

Being able to work wherever, from wherever, is also attractive. But wasting my time and energy on what I find to be counter-productive noise -- that's the worst.

I'm actually rather good at collaboration, including face-to-face. I refuse to sit next to someone and work to ignore them, for hours on end, when there is no point to it other than achieving a "best practices" (read, square footage and most superficial measurement of cost reducing) workplace.

So, I have this "attitude". (I don't express it as such; instead, I politely request and explain my preference.) Yet I've repeated ended up being the person with an extensive network throughout very large organizations. I help other people out, and some of them remember this and return the favor. (I inevitably end up finding a community of like minded individuals.) Real collaboration, as opposed to simple co-location.

P.S. Sigh. Sorry if I got a bit ranty, here. But this topic really pushes my buttons. In the "corporate" environment, I'd be repeatedly lauded -- highly -- for my work. But when I broached this topic -- a polite request for a quieter workspace -- it was, officially at least, a non-starter. Certain managers did what they could, unofficially. Others were simply critical.

Too many people want "high performers" -- and lament their dearth -- but they refuse to listen to those people's real requirements.

And I've too often seen arbitrary edicts substituted for real, attentive, you- have-to-work-at-it-and- _earn_ -that-big-salary management.

I can understand the "other side". But, individually, I've come more and more to the decision to lend it little of my respect.

<comment><USER4> I saw last night that someone responded to my comment, but I was too tired to read it thorouhgly and address it then and left it for today. I see now that that response is gone.

I hope that, "rantiness" aside, I was and would address the topic in a respectful (at least, as regards the conversation here) and productive fashion.

I do get... "agitated" about this topic, because for so long I was told that I was the one who needed to adjust and accommodate and "get used to" the status quo (ever noisier shared workspaces). And I tried. And tried. And tried....

It didn't get any easier for me. Even when I would deliberately pick out noisy cafes and try to work there in order to "train" myself.

I wasn't asking for the world. Just for a quiet workspace. I didn't mind people interrupting me for a purpose. I just didn't want to spend my days tuning out activity that did not directly involve me.

And much of that activity, in my particular environments, was not even work. It's very frustrating to be trying to be trying hard to get something done while your cubemate is engaged in their daily, extensive socializing.

Let those who do such rise or fall on their own merits. I'd rather stay out of that. Just don't disrupt my own work, while you're at it. And don't tell _me_ to "get with the program", when I finally point it out.

</comment></comment></comment></comment><comment><USER5> Start up spirit equals:

offices are covered in chalkboard paint and whiteboards, for scribbling down ideas and code, and also feature a fully stocked kitchen. They are decorated with posters of software applications the employees admire and aim to compete with. The team has also installed two large television screens for testing app prototypes and has built a game room with club chairs.

<comment><USER6> epic funny this. but more scary, probably not too far off from truth.

</comment></comment><comment><USER7> I've often thought about these larger companies who superficially try to take up the characteristics that make start-ups great without understanding the underlying cause.

I've narrowed it down to a few big reasons, but the number one driver I've come up with is desperation. When you have an ever shrinking runway, a small staff, but a glimmer of hope that there is a way out and a shared vision of some great outcome, that is when you develop a start-up culture. Not by adding snack foods and soft drinks.

But then again, this article seems to point to Facebook and Google as having the start-up spirit so clearly they are talking about some other phenomena Yahoo is trying to adopt.

</comment><comment><USER8> Cultural problems cannot be solved by throwing money at them.

</comment><comment><USER9> Surprised to see myself in the article, forgotten I'd given that interview.

</comment><comment><USER10> Start-up spirit after 20 years.

Hey, we're a startup, take a pay cut and work 80 hour weeks. Here's a free soda. Let's make Yahoo great, we're in this all together. [http://money.cnn.com/2012/07/19/technology/yahoo-ceo- pay/ind...](http://money.cnn.com/2012/07/19/technology/yahoo-ceo- pay/index.htm)</comment>


Applications for YC W2015 now open - <AUTHOR> http://www.ycombinator.com/apply/ <comment><AUTHOR> The tech powering the application form is completely new this year and was rewritten from the ground up by the YC Software Team. A lot of the credit goes to Brett Gibson for implementing an ungodly amount of features needed to handle not just accepting the data, but migrating old applications, building tools for reviewers and having it all work seamlessly with HN. Anything that doesn't work is probably my fault.

One thing that's new is we separated out a separate form for each founder to fill out. Not sure how that's going to work, but hopefully better. We'll probably keep tweaking the interface over the next few weeks, so if you have any feedback about the new flow, we'd love to hear it.

<comment><USER2> New application form looks great. Kudos to Brett!

I just have one feedback : There are some questions that are correlated with the previous ones. When this is the case, you may remove some of the questions by considering previous answers.

For example,

"Which of the following best describes your progress?" After I answer this question as "Launched", it still asks the following question "When will you have a prototype or beta?".</comment></comment>


Ambiguous forms. So, do I type the http or not?  - <AUTHOR>

Is it just me? Each time I encounter a form that asks for my website URL, I spend a second or two wondering if I should type it with or without the http:// ; based on what the site looks like, I have a hunch on which one's better, and I enter(or don't) the http://<p>While most forms are/should be built to handle this, I've had a http://http:// happen a few times. <comment><USER2> Good form handling code will only attach aa <http://> if there isn't one already. It's a shame that so often you find websites which don't handle this correctly.

</comment><comment><USER3> By definition, the scheme name is part of the URL. A form not accepting properly formed URL is broken. If they add the <http://> prefix without informing the user, shame on them.</comment>


Why I'm an ebook convert - <AUTHOR> http://www.guardian.co.uk/commentisfree/2010/feb/15/charlie-brooker-ebook-convert

<comment><USER2> Amazing how 9 out of 10 comments on that article are about how ebook readers are a silly fad. I don't even own one and even I can see paper books are soon going to be second choice, behind digital versions.

</comment><comment><USER3> Good for Charlie. I love my Sony PRS500. Ok no wifi or fancy (it does play mp3s!), but it was $150 for ebay, so when I driopped it and a bit of the case broke I just stuck some duct tape on it and didn't care.

I've filled it with stuff from Gutenburg, stuff you can't even buy if you wanted to. It'll be a long time before I've read my way through the free stuff. And by then I'll be able to bay a fancy one.</comment>


New studies confirm existence of galaxies with almost no dark matter - happy-go-lucky https://news.yale.edu/2019/03/29/new-studies-confirm-existence-galaxies-almost-no-dark-matter <comment><AUTHOR> I didn't look at the other one but NGC1052-DF2 is consistent with MOND:

      Original sigma      = 7.8 (+5.2/-2.2)
      New sigma           = 8.5 (+2.3/-3.1)
      "Crude" MOND sigma  = 14 (+4/-4)

[https://tritonstation.wordpress.com/2018/04/04/the-dwarf- gal...](https://tritonstation.wordpress.com/2018/04/04/the-dwarf-galaxy- ngc1052-df2/)

And keep in mind these uncertainties are arbitrary cutoffs...

Also, others claimed the distance they use (20 Mpc) is wrong. It should be 13 Mpc and this throws off the calculations: [https://arxiv.org/abs/1806.10141](https://arxiv.org/abs/1806.10141)

I see them still using the 20 Mpc value without addressing those concerns.

<comment><AUTHOR> Thinking more on this... Those are either 90% or 95% confidence intervals (couldn't tell from the recent paper).

So that would mean if you looked at 100 galaxies you would expect 10 (or 5) to fall outside the range _if the model was correct_.

</comment></comment><comment><USER2> _Am I wrong to conclude that this result itself is an argument for the existence of dark matter?_

Because the theories that argue that physical laws behave differently at larger distances would have to work similarly for all galaxies. Physicists please correct me if I am wrong in making this conclusion!

<comment><USER3> I think that is a reasonable conclusion to make (assuming these findings are correct). The article says the same:

>Ironically, the lack of dark matter in these UDGs strengthens the case for dark matter, the researchers say. It proves that dark matter is a substance that is not coupled with normal matter, since they can be found separately.

<comment><USER4> This reminds me of the discovery of oxygen, which was more about discovering the _lack_ of oxygen in a vacuum and in combustion products.

<comment><USER5> [https://en.wikipedia.org/wiki/Phlogiston_theory](https://en.wikipedia.org/wiki/Phlogiston_theory)

</comment></comment></comment></comment><comment><USER6> This leads to an interesting question the article didn't mention...

If a galaxy can exist without any dark matter and others with a balance of dark and normal matter, can one exist made entirely of dark matter?

<comment><USER7> If you could play God and place blobs of dark matter in the right places and moving at the right speeds, it seems plausible that such a dark matter Galaxy could physically exist and be stable.

But I don't think we know of a mechanism for such a structure to form naturally. Normal particles collide and transform some of their gravitational energy into heat. If dark matter only interacts gravitationally, blobs of it would pass right through each other without losing energy. I think(?) you need these sorts of collisional energy losses to get matter to coalesce into a galaxy.

<comment><USER8> You can get the equivalent of evaporative cooling in an unstable multi body system. You occasionally kick out an object which takes more energy away than the average body that remains.

The formation of a dark matter galaxy in such a fashion is plausible, but would take a long time.

<comment><USER9> That require that the bodies exchange energy to get near the lower average, and transfer some energy to a few hot particles. Otherwise, you won't get any cooling.

<comment><USER10> That could be done entirely through gravitational mechanisms. There's something like that which happens to globular clusters.

<comment><USER11> You might be interested in Lynden-Bell's papers

<comment><USER10> Thanks. I'm just going by a tidbit from DeepSkyVideos on YouTube. They specifically mention a similarity to evaporative cooling.

I just found the video! ("Gravothermal Catastrophe")

[https://www.youtube.com/watch?v=LYnoV2n5ptg](https://www.youtube.com/watch?v=LYnoV2n5ptg)

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Can a physics minded HNer confirm something for me (or set me straight)?

One piece of evidence for dark matter is observed when galaxies collide. Two galaxies collide, but by observation of gravitational lensing on the light from stars "behind" the colliding galaxies show that much of the matter from each continues moving. This matter (dark matter) is seemingly unobstructed by the collision (because of dark matter's lack of electromagnetic interaction).

I heard this explained to me once, wondering if it is true.

<comment><USER13> > because of dark matter's lack of electromagnetic interaction

This is still an assumption, because we don't know for sure that dark matter is only weakly interacting, but this is what was observed in the Bullet Cluster collision: [https://en.wikipedia.org/wiki/Bullet_Cluster](https://en.wikipedia.org/wiki/Bullet_Cluster)

There's a good explanation here: [https://astrobites.org/2016/11/04/the- bullet-cluster-a-smoki...](https://astrobites.org/2016/11/04/the-bullet- cluster-a-smoking-gun-for-dark-matter/)

The lensing was found to be strongest near the visible matter (stars), and the amount of observed lensing couldn't be accounted for with the total stellar mass alone. So the assumption is that the dark matter, like the stars, wasn't slowed much by the collision. The gas, on the other hand, interacts electromagnetically and slows down in the middle.

That's not to say that the stuff that stars are made up of isn't affected by electromagnetism, but it's a short-range effect and even in a collision, interstellar separation is large (i.e. contrary to what you might think, a galaxy collision doesn't involve all the stars smashing into each other, most of them will just sail right on through). Gravity will dominate in that case.

<comment><USER14> "Gas", here, as usual, means "plasma". Gas does not interact electromagnetically.

Use of the term "plasma" invites banishment from the community of astronomers, and loss of access to telescopes.

<comment><USER13> It's referred to as plasma in the primary literature: [https://arxiv.org/abs/astro-ph/0608407](https://arxiv.org/abs/astro- ph/0608407)

Many people use hot/ionised gas and plasma interchangeably though. For example: [https://academic.oup.com/mnras/article/389/2/967/974617](https://academic.oup.com/mnras/article/389/2/967/974617)

</comment></comment></comment></comment><comment><USER15> What I've never understood about dark matter is if it doesn't interact with the electromagnetic force, why is it found in voluminous clouds instead of collapsing into dense discs or balls? Radiation pressure doesn't affect it, it experiences no impact or friction effects, no thermal effects, so why doesn't it fall to the middle of the galaxies and stay there?

<comment><USER16> Why should it stay there? Imagine you had a sphere of particles with an initial velocity of 0 that interact only through gravity. At first, these particles would all accelerate towards the center of gravity. Once they reach the center of gravity, they would have accumulated some velocity, and so continue to travel away from the center of gravity (but still be accelerating towards it). Eventually, the acceleration towards the center of gravity would 0 out their velocity again, and they would start falling back towards it. The end result is that your original sphere oscillates indefinantly, but always returns to its original state.

As your initial configuration becomes more random, this discernible time structure begins to fade, and you end up with a voluminous cloud.

What allows regular matter to collapse into dense structures is that it interacts with itself to shed velocity.

<comment><USER15> So then why is its structure and location correlated with galaxies at all? Shouldn't it be relatively even throughout the universe?

<comment><USER17> I think this is roughly the question why are there galaxies (and clusters, and stars) at all? And the answer is that the primordial soup wasn't perfectly smooth, and gravitational attraction has the tendency to make clumpy things more clumpy. Precisely how un-smooth the soup was, and how clumpy galaxies are today, is quite a large part of the information we have about the history of the universe -- the CMB is a snapshot of the soup right when it came out of the kitchen.

If dark matter was just like matter, then you'd expect it to go along for the ride, and exist now mostly in the same places (and at the same contrast) as normal matter. If it were something else, then its distribution could be much less clumpy, and I think this is a constraint on what kinds of things are plausible candidates.

</comment></comment></comment></comment><comment><USER18> Possibly dumb question: Do we know the dark matter proportion of our own galaxy? (in other words, how hard is it to take a selfie, at galactic scales?)

<comment><USER19> The existence of dark matter in galactic halos is inferred from the velocity dispersion of stars in a galaxy (sigma). It's important to realize that this is a very rough kind of estimate because every aspect of it (as in the case of the M-sigma relation) is roughly estimated. Virial mass is inferred from average temperatures of gas by way of detexting X-rays. Central black hole mass is inferred through the M-sigma relation, and stellar masses are inferred through luminosity. Every so often a new paper comes out revising the overall estimates, but the _proportion_ of DM to luminous matter stays pretty constant.

Now, in a sense this makes a "selfie" easier, because you just need a series of snapshots which help you make all of these inferences. On the other hand because we're in the disk of our galaxy it is difficult to image because we have to deal with all of that hot interstellar gas and dust, and the extremely bright galactic core. I'm not sure how much, when you take into account a long period of time and many wavelengths can be observed, but I'd say we can observe the majority of our galaxy in at least one wavelength. Still, we're not talking about "selfies" here, just really well educated guesses based on observations of our own galaxy and similar spiral galaxies.

So as far as inferring the existence of a dark matter halo in our own galaxy we're pretty certain, and it seems to make up about 95% of the galactic mass. It's based on something a lot more tenuous and complex than a "selfie" though. Once you've done your best to estimate the total luminous mass of the galaxy and it's rough distribution though, and ruled out MACHOs with lending surveys all that's left in the remaining narrow window is dark matter. The only other theory with any chance at all is MOND, but it has to thread crushingly narrow passages between observation and tests of GR.

<comment><AUTHOR> >"[dark matter] seems to make up about 95% of the galactic mass...crushingly narrow passages between observation and tests of GR"

GR only matches observation because you added in 20x more stuff that is undetectable other than as a deviation from the predictions of GR.

<comment><USER19> That's true, but it's also true that hypothesis is preferred because of the abject failure or other theories and hypotheses to match those observations. The window for something other than DM is exceedingly narrow and only MOND has a hope of fitting through, and currently not in a form that's very compelling.

<comment><AUTHOR> The point is this "window" isn't narrow at all once you allow dark matter.

Practically any theory plus 95% "dark matter" can match the data.

</comment></comment></comment></comment></comment><comment><USER20> Wow. From my armchair it seemed to me much more likely that physics just works a different way at that scale than that there was an invisible substance magically sprinkled evenly throughout most of the universe.

<comment><USER21> Also from my armchair view as well.

Both of these galaxies are UDG's, keep in mind.

In my uneducated opinion dark matter is an outcome from cluttering too much gravitational force in too small a space.

</comment></comment><comment><USER22> Are there any alternative theories that invoke strange interactions of matter/gravity/etc with time? I guess the gravitational wave results out of LIGO would indicate that it propagates across time in a fashion similar to electromagnetic radiation, but if gravitational effects extended beyond 'now' there would seemingly be a possibly small cumulative effect.

<comment><USER23> One alternative is 'Process Physics' which is not widely accepted but has a fundamentally different explanation for dark matter: Turbulence in the in-flow of space into matter. This flow is PP's model for gravity itself, as if matter continuously 'consumes' space to continue its existence. It's an interesting, quite different and generally totally rejected point of view.

</comment></comment><comment><USER24> I had a naive theory that there is a limit to black hole size/mass that once reached causes gravity to have a more linear strength instead of the inverse square. This discovery blows out that pet theory.

</comment><comment><USER25> This would seem at first glance to be evidence against entropic gravity?

</comment><comment><USER26> Could it be that we simply cannot observe all of the actual objects a galaxy contains, and thus we maybe do not need another theory or dark matter?

<comment><USER27> Pretty much all massive objects except black holes emit light/radiation, and black holes, afaik, are detectable. Thus there's something else that we give a placeholder name "dark matter". It's possible it's not a matter of any kind at all, but just some very smooth but irregular field that interacts with the space-time curvature (gravity).

</comment></comment><comment><USER28> Today it is dark matter, but tomorrow it is... [https://i.imgur.com/YcsVKGX.png](https://i.imgur.com/YcsVKGX.png)

</comment><comment><USER29> I don't believe in the dark matter as they are currently selling it. I think we have small eyes on the universe and are missing information we'll probably never get at our scale.

The missing energy could be giant elementary particles (in the standard model), and these "particles" go to bigger-than-black-holes energy, which we could never gauge in a lab, tho I'm pretty sure they can be "predicted" along an energy scale.</comment>


How libertarians might prove useful -- and vindicate Calvin Coolidge - <AUTHOR> http://www.powerlineblog.com/archives/2014/07/where-are-libertarians-when-you-need-them.php

<comment><USER2> Change mostly happens on the margin in relatively small increments. Libertarians are actually _making progress_ at legalizing pot, which is great because the war on pot has long been a gateway drug driving the increased militarization of the police. They've also been making progress getting rid of dumb archaic laws (like those that prohibit sodomy or gay marriage) and fighting against the _growth_ of _new_ incursions against freedom, even if it is a rear-guard action.

Fighting "the regulatory state" as an abstract project seems quixotic, unless you have an actual PLAN for doing so. Besides, when libertarian forces DO try to attack the regulatory state too directly, they tend to get marginalized by the left AND the right, as happened with the Tea Party.

One underlying problem is that we don't currently have anyone as prominent and capable as Milton Friedman arguing the issues. There are some great econobloggers (eg, at [http://econlog.econlib.org/](http://econlog.econlib.org/) ) but none sufficiently prominent to serve as a counterpoint to Krugman. There are a few libertarian celebrities (eg, Penn Jillette) but they don't have the gravitas to get taken seriously in intellectual debates.

</comment><comment><USER3> So libertarians should avoid actual, relevant, concrete issues surrounding personal freedom, and that people care about, in order to concentrate on abstract Republican rhetoric (that Republicans have never carried through on, expanding government as much or more than Democrats)? Sounds like a dumb plan.

<comment><USER4> Another way to phrase it is libertarians should focus on the heavy lifting of reforming small pieces of government where they are likely to have success rather than focusing so single-mindedly on issues they are unlikely to have much impact on.

</comment></comment><comment><USER5> If libertarians controlled the school systems, then mainstream liberalism would be a fringe movement.

</comment><comment><USER6> It's so funny, but I have to say it again, libertarians are not a subgroup of conservatives, so please stop talking to us like we are on your side.</comment>


China Sends Message to Trump Through Stock Market - <AUTHOR> https://medium.com/behind-the-great-wall/china-sends-message-to-trump-through-stock-market-a4f8fea93c35 <comment><USER2> The CCP should make its propaganda slightly more subtle.</comment>