euank

Of course, the entire premise of this operating system is that VMs are secure, even though there have been exploits targeting them in the past [0].

Disabling virtualization capabilities in the bios is a semi-common recommendation for securing a computer... Still, this OS is a darn sight better than nothing and it'll certainly protect against most things. However, touting it as perfect is misleading.

[0]: https://en.wikipedia.org/wiki/Blue_Pill_%28software%29

Not necessarily that the distro security team codes the patch even. In most cases, upstream (e.g. openssl here) should have an official patch/commit that is private, but is given to these trusted distros. The security team only has to create a package with the upstream patch.

Other than that, yes, that's exactly the notion.

Not so; companies like RHEL understand the importance of disclosure timelines and won't leak it early.

The importance of telling large distros doesn't lie in them immediately releasing a fix; it lies in them being able to prepare a package with the fix before the announcement, and then exactly when the announcement happens, they can publish the package (and possibly do something to make it propagate faster to their distribution servers)

As is, when Heartbleed was announced, many distros took an hour or significantly more to offer a fixed package. Proof-of-concept exploits were also made in that time. That was a dangerous situation.

I fully expect critical vulnerabilities that are "responsibly disclosed" to be reported to major distros so that packages can be prepared, but not released, in advance; furthermore, it allows people to be ready when it's announced at an agreed-upon date so that the packages can be pushed to live.

I'd actually be okay with a system where smaller distros which use similar packaging formats to larger ones are alerted with "There is an exploit. We will publish a fixed package that will likely be compatible with your distro on DATE. Be awake then to make sure these changes go live quickly, not when one key dude wakes up in 5 hours".

Sorry for the long-winded comment. What I really wanted to do is just explain "no way to share ... deploy a fix ... without making it public" is not the reason for sharing. The reason for sharing is so that the fix can be deployed more quickly when it is deployed.

Ah, yes, certificate patrol[0]. However, your argument, I think, is not valid. Sure, it's technically possible for him to know if any cert changes, but in reality very few people are going to install the extension and those that do might not even notice the message because it notifies the user so frequently (fully desensitizing them I imagine).

I don't think that his choice not to install an extension invalidates his argument.

[0]: https://addons.mozilla.org/en-us/firefox/addon/certificate-p...

I personally use the silver searcher[0], also known as ag, which is .gitignore aware and I find quite quick and useful.

In fact, ag references git-grep in its readme while this blogpost makes no mention of ag. I suspect the author just doesn't know about ag or doesn't want to install an additional less-standard package... I personally find it worth the installation.

[0]: https://github.com/ggreer/the_silver_searcher

That sort of power through USB is unrealistic.

The other bit, motion detecting, would rely on closing the lid not sleeping the computer (as a thief will generally close the lid before taking the item)... Most people have that, but it can be disabled.

It would probably make more sense and be more feasible to have the USB stick be the alarm, and have it sound if the computer is closed while it's in.

However, that sort of thing is so easy to fool that it would have to rely on not getting big enough that thieves learn to work around it.

On the https://couple.me/alice page, to make text appear a little at a time they setup a long series of timeouts set to trigger at different times (as you can see here: https://couple.me/javascripts/alice.js). They are not dependent on each other.

This leads to unusual behavior if you do something as simple as tab away while one of them is playing for about 10 seconds. On both Chrome and Firefox, that will result in, when you tab back, complete gibberish as multiple timeouts that triggered while you were away both begin "typing" their text. I think the correct solution here is to have all callbacks drawing text depend on the previous one completing (since there's no overlaps, this should work well enough).

That entire sequence also felt very trite to me, but I can see how it could be appealing.

I can't help but think that they already were in a sort of informal alliance.

It took Google dropping prices for both AWS and Azure to drop... clearly they were both skimming profits off the top for the last while.

Of course, a company does need to profit and I'm not accusing either of them of doing anything wrong, I'm just trying to say that these sorts of alliances form accidentally and naturally; both companies hit a competitive price and then hardware gets cheaper; software gets better... they could drop prices, but why cut into profits when there's no need? Inertia is a powerful force. It takes something actually happening to kick those price drops into action, generally.

Both AWS free and GCE require a credit card before doing anything at all, so that's not a barrier.

As for the actual price... GCE's cost of .013c / hour is so tiny that I don't see how you can say it's a "huge deal".

You can spin up a GCE for 5 hours a day for a week to experiment and it'll cost you less than 50 cents. It's not quite free, but it basically is. As long as you're just playing around, always-on shouldn't matter so you can spin the server up to play, down when you're done, and thus pay almost nothing.

It would be nice if glass came with a physical cover attached that can be slid over the camera lens. Thus, you could have the lens normally covered and still use the glass without others being uncomfortable. As long as the cover became a widely recognized symbol, it could allow for social cues to develop separately around wearing "blind" glass vs regular glass.

The physical cover would of course also prevent this type of malware.

Though it's not advertised on the landing page, Lightbeam has a block functionality: https://www.mozilla.org/en-US/lightbeam/

It's also endorsed by mozilla, which makes me trust it more. I've been using it for a while (on top of noscript) and it's quite informative and seems to work well.

My personal setup is noscript with careful whitelisting which I've found to effectively disable most tracking.

I personally don't like this idea. Different people will have drastically different standards. What is wrong or right for a project, to me, depends on the standards of the developers and users. In this case, the jury is neither.

In some communities, otherwise offensive phrases have been desensitizes or misappropriated. Those communities might have projects which are only used by them, but are public on github.

Somewhat similarly, most of the repos on github are single-contributor "private" projects that just happen to be public. I see nothing wrong with them expressing whatever they want in their code and comments... but I do think it's out of line for a third party to come out of the blue and cast a ruling on it.

I can see the argument that "Oh, it's just a pull request, they don't have to accept it", but I still don't like this project as a whole.

I don't think the repos with offensive words or hate speech are driving people off of open source or github or coding, only off of those specific projects - as they deserve.

It's not mickey mouse, the extension of copyright that resulted. The point he's making is that a big business (Disney) can sway legislature for their own benefit.

If you're not aware, the copyright period has been extended several times up to the point of ridiculousness based mostly on Disney's lobbying.

Patents are a massive problem in tech, but copyright is a problem for innovators in the arts - especially authors.

The insult at the end is entirely unneeded. Hell, I wouldn't be surprised if a child saw the issues presented more clearly for not having had to deal with reality nearly so often.

You can transfer cash to someone else cost free, tax free, and paperwork free if you don't mind breaking the law. If you transfer money by other means (e.g. the bank, bonds, etc) there are perks that make up for the additional cost generally. If nothing else, simplicity.

You really think it can't be devalued by the government?

Its value changed when China implemented laws regulating it (and even when there was speculation of it).

If the NSA threw its resources at mining, it could become rich and then dump for cheap, thus crashing it.

The FBI already showed that they can seize some, and they managed to seize such a significant portion that it could be devalued that way.

What you should be saying is "It's not backed by a central authority we have to trust". A third party as powerful as the government can still do significant damage to it.

>more efficient way to transfer money

In addition to your stated issues (which actually are probably fixable), there's the computational power requirement. That cannot be fixed. Bitcoin requires thousands of times (or more) more computational power to do a single transaction than any centralized currency system I can think of.

I remember before bitcoin people would say "Oh, I have a couple spare computers... I just threw folding@home on them for now". Now, people are going out of their way to throw cycles at this currency instead of problems that help scientific progress, and thus humanity.

Bitcoin is a cool idea and well implemented for what it is, but I think attention should be drawn to its exceedingly inefficient use of computational resources.

A sophisticated attack can completely imitate 2FA.

The first bit: It starts by asking for a username+pass and it uses javascript to async-post it. The evil server then tries to login to google. If google returns that a 2FA is needed it prompts for it.

I have no clue what you mean by "through google's api"... An attacker does not have to follow an api. Anything the user can do with their browser, the attacker an imitate on a remote server. Absolutely anything except source ip.

Your entire "no way of doing this using code" makes no sense at all. Posting data is something that can easily be done programmatically. Posting data through a middleman is similarly easy.

The only way that 2FA helps (edit: as alcari points out, this doesn't help much) is that the attacker can't change your password because on initiating that, I believe google asks for another 2FA code, and I don't think the attacker could reasonably expect to get you to enter two 2FA in a row. It also does make it harder for the attacker to code it up, but it's not even that much harder.

I think you got a detail wrong.

I think that the app can only access all users registered with its api key. Same for passwords.

You say "all users registered on the site", the api says "Note, this can't be used to lookup just any user's password – the user must have been created by the API account."

See: https://news.ycombinator.com/item?id=7358532, my reply a to a sibling comment.

That still does not follow. It proves that he lied about not knowing what bitcoin is and it proves that he had bitcoins. Those two facts do not prove that he is Satoshi. It is not obvious.

Here, I'll give you an alternative explanation: Dorian was an early bitcoin adopter or otherwise had a small number. When reporters started asking his son if he was Satoshi, he realized that that would damage his reclusive lifestyle if people thought he were Satoshi. He thought that telling the truth, that he knew about bitcoin but wasn't Satoshi, wouldn't be believed so he told a lie to preserve his reclusive lifestyle.

Unfortunately, that proves nothing.

Early on, there were so few people mining that practically everyone had a "large volume". As such, if you pick any arbitrary bitcoin transaction at that time, it's highly likely it will have originated from a large volume source in the recent past.

I think it's more likely a case of mistaken identity; there are many people in this world, and I think that the chance of someone remembering someone from 3 years ago that they saw for half an hour, tops, with sufficient accuracy for a positive ID is much lower than the chance that there are simply two middle aged asian men who look vaguely similar. It's also improbable that "satoshi" would fly across the country for this purchase. One person's word is certainly not compelling to me.

Even if that account is 100% accurate, it does not link the man who paid with bitcoins to satoshi, but merely to Dorian. The HN link relies on the flawed NewsWeek article to make the further connection from Dorian to Satoshi.

It's a shame this is being upvoted so highly when it's factually incorrect. A rebuttal can be found here: http://nmav.gnutls.org/2011/05/is-really-gnutls-considered-h...

It's rather silly that the news of a critical bug in GnuTLS that was caused by a goto somehow makes non-news and factually wrong information from 5 years ago popular.

He addresses that. The browser has a different security model than the OS.

The OS's model is based off of the user being the unit of security. If a user runs a piece of software, that software can interact with all files owned by the user. It can make web requests to anything.

The browser's model has the unit as the webpage, not the user. Each webpage is sandboxed from others. If one webpage is malicious, in theory it cannot modify users files or even other webpages.

The difference in model makes a malicious webpage significantly less scary than a malicious program.

Your example, of running your whole OS in the browser, is unrealistic; in reality you'll be running each piece of the OS in a different isolated tab.

This model can work since the web was built for each site to be independent and self-contained... We've already gone too far down the rabbit-hole of native programs being extremely powerful to easily fix that.

The OS might not be lost though. You can run scary software in a VM. You can run each program in a separate chroot. Perhaps soon you could just spin up an lxc (with docker perhaps) for each different program you want to run. These methods of running software all basically transform the OS into using the browser's model.

It's also worth mentioning that the browser model has inherent security flaws for as long as it persists the executable on external servers; you have to find a trusted channel to access the data everytime whereas the program only has to be verified once after downloading.

Consider trying Tox, http://tox.im/ ... It's open source and actively in development, but already at a usable stage. It's meant to be akin to skype, but open and secure.

If you read the context, it's quite clear that he's only referencing his own bitcoins.

    [12:02] <JonWickedFire> How much did you lose yourself?
    [12:04] <MagicalTux> Well, technically speaking it's not "lost" just yet, just temporarily unavailable
    [12:05] <JonWickedFire> Well, how much is unavail for you?
    [12:06] <MagicalTux> I'm not even sure
    [12:06] <MagicalTux> didn't check my wallet before pushing the site offline

That final line makes it very clear that he meant he didn't know how many BTC he had in MtGox and thus "lost". How you clipped it, it makes it sound like he might mean he doesn't know how many are temporarily unavailable on mtgox as a whole.

We aren't "running out of bits", but we have a highly limited amount of time and screen real-estate.

The reason it was marked as such was so that other people didn't waste time on an unreproducible problem until it was fixed to be reproducible.

At worst, it sits there and wastes many people's time, thus getting in the way of actually reproducible questions getting seen and answered.

Note, that this is not regarding this one question, but thousands - certainly there are a large number of items selected for moderator action.

Not him, but I can see a few good reasons.

GPL is rather limiting in how you can use the code. A large company (e.g. Apple) won't let something gpl be used heavily internally if they can help it since they won't be able to apply patches or modify it without releasing these changes ... this obligation adds significant legal burden and, furthermore, releasing the changes could reveal private details about the companies internals.

I don't think that the commentor's reason is a good one, but I can understand the viewpoint; GPLv3 is quite limiting for some uses.

You can get out of vaccinations in many situations with a) a doctor's express diagnosis that you should not be vaccinated or b) claiming to have a religious reason that prohibits vaccination.

These methods might not work for all universities, but I know they work for some.

No, they can't. The websites allow anyone in the world to make a guess at a password. Keepass doesn't since it requires having the private database file which you store locally.

The websites allow for a vulnerability in third party code to expose you. Keepass, even if it has a vulnerability, can't be exploited remotely since the database is stored only locally.

The websites are in the browser and encourage browser extensions. Browsers suck for security... that's a massive attack surface and they are, by their nature, integrated with the network. Keepass is a dedicated application with a tiny surface that barely communicates with the internet at all and has no need to. A whole class of attacks miss it.

Keepass is leaps and bounds more secure.

There were 439 lines changed in this commit. Clearly it was an exaggeration, though it was an oddly specific one.

I think this deal is poorly thought out since, coincidentally, all of your bitcoin wallets are in fact data. I'll happily pay whatever sum of BTC into a wallet in exchange for that wallet + some more data. Nothing but gain.