Still dont get it.
3,870 karma · joined February 25, 2013
Still dont get it.
s/world-wise/world-wide/
_________________________
And that's correct. I put no state-of-mind or otherwise speak for her. I'm acknowledging the complexity of highlighting a potential problem amongst your peers in a very public manner. Especially in Academia, where your peers approve, collaborate, and act as a peer, attacking them publicly could have disastrous consequences.
It is "safer", and provides face to be accepting of such actions, be they intentional or unintentional.
(Yes, I work in Academia. This sort of thing happens pretty regularly, from what Ive seen. What's that saying... The nail that sticks out gets the hammer?)
But I would imagine that a simple 3d printed harness would work a lot better with allowing signals to be recorded and make the printer think its printing. Then the bypass harness could have an ARM on it and spool instructions to either a SD card, or via USB serial.
The goal here is as transparent as possible, just in case there are other security systems that try to detect this attack. But I'd guess they havent got to that point yet.
Printing in different inks also wouldn't show us a way to diff 2 printed images. Whereas, saving the pulses from the CMYK pins would do that.
When you have a datalog of lots of pulses that represent a picture, you can back-calculate it into an image. You can also diff it without relying on losing data from scanning (or paying attention to the wrong thing). And with enough samples, we can recalculate the algorithm. With the knowledge of what they're doing, we can then start scanning other images for this... But only once we know what they're doing.
Also, intentional namespace pollution with existing backup tool, which IS gpl'ed.
Not cool. Not cool at all.
____________________________________
(response, since I'm submitting 'too fast'... ):
Github has commercial repos, and private repos.
It's pretty simple, really. If you want the free options on GH, you choose from a list of standard Open Source licenses. https://github.com/blog/1964-open-source-license-usage-on-gi...
It's also asked you create a LICENSE file, to go along with this.
Their license, however, is very much NON-FREE. As in, if I click clone, since I work for an employer of 50k people, I'm in violation. Full stop. And we're not even talking about developing on it, or submitting PR's, or what have you. This is simple copy which puts me in violation.
It's very much against the spirit of GitHub, and probably against the license on GH as well.
And it also is attempting to dilute another project that does similarly. Just so happens they're 2 letters different. Duplicacy vs Duplicity. That's an asshole thing to do.
Here's a few names I just devised: ClouDuplicate , Clouder, DupliCloud, CfC (cloud file cloud)..
Instead, it's very uncool to try to pollute an existing namespace of the same thing. Talking about pro-level bad will here.
One way I can think of, is to record data on the CMYK pins on the inkjet head itself. IIRC, they activate between 17v and 22v, and pulse per high.
The goal here is to make the printer think its printing, while recording all the data of the pulse operations. We would get a lengthy file out.
Ideally, the pulse coding should be consistent if printing the same image. "Printing" the same thing over multiple times could show time/date codes embedded.
I should also be able to compare underlying system internals too, with multiple clones of VMs with small config details different. They should be the same data. If they aren't, we know its encoding system stuffs.
But yeah, there is a way to attack this, and that's by going lower in the stack and treating the printers as a black box. It's not the best way, but a way I've thought of that could at least detect this new technique.
I believed that Ethereum initially had an interesting idea. I thought their system had little rigor in the way Bitcoin does... but I'm willing to look over pre-alpha stuff for the underlying concepts.
Tl;Dr. Showed up on top of HN. Greatly interested in the concept of compute-blockchain, but dissuaded of Ethereum specifically of company policy/choices.
If she was to attack her colleagues, it would spell certain doom for her career. Her opinions and proofs would be dismissed and denigrated. And the specter of "Will I be accused of sexism if I pan this paper?" will rear its ugly head anywhere she would turn.
Think of this as an analogy to badmouthing your previous employer in an interview. You just don't do it. Except, now exchange interview for world-wide public debate/discussion. Nobody in the world, in that field, would consider her.
No having to dork with servers one at a time. And with Ansible, if I change puppet manifests, I can reload puppet with ansible instead of waiting the default 30m.
https://thepiratebay.org/torrent/16102495/13th.2016.NF.WEBRi...
So did the Ethereum Devs, who owned a bulk of coin from the initial auction. And they just so happened to also control development of the protocol AND the client programs. This was the message they "asked" users... https://upload.wikimedia.org/wikipedia/commons/thumb/d/d7/Et...
"....IN WHICH FUNDS RELATED TO THE EXPLOIT ARE RESTORED...."
Consensus is nice, especially when you can manufacture it. Noam Chomsky talks about this in great detail. https://www.youtube.com/watch?v=tTBWfkE7BXU
Chomsky: "The first place to look is, who's in a position to make the decisions that determines the way a society functions."
http://www.alternet.org/environment/7-toxic-assaults-communi...
http://www.usccr.gov/pubs/envjust/ch2.htm
http://www.environmentalhealthnews.org/ehs/news/2012/unequal...
https://www.scientificamerican.com/article/people-poor-neigh...
Regardless, the very people who build the protocol, application stack, and seed blockchain machines were also the ones who had massive stockpiles of eth from the auction... You do remember the auction, right?
They had absolute fiduciary reason to undo their losses.
Edit: And in all honesty, this would be compute-expensive, but the nature of the blockchain would be able to tell how much ethcoin came from before the auction rather easily. After all, a blockchain is just a append-only distributed ledger. Well, we did know the transactions, but you'd likely have to go to Ethereum Classic and replay what addresses put money in.
"The Contract is the Code, and the Code is the Contract."
It was a programmers no-man's land where anyone could stake a claim, and start doing cool stuff. And if you screwed up, it was your fault. Nobody else's. And you had to watch out, because it was easy to lose money into nothingness (yeah, BTC had checksums, Eth didnt - another point of amateur hour).
Until the DAO.
When that happened, I think $150m of Eth went into it. Massive amounts. The idea was to have a distributed living self-autonomous company. And, by the older ideals, lots of someones didn't do their homework. Or they did and it was intentional. Regardless, the "completely innocent magnanimous leaders of Ethereum" decided to force a Blockchain split, and rewind it all. Of course, Something like 2/3's of the total amount was owned by Ethdevs. Surprised? Nope.
Bitcoin? Sure, I'll play. But Ethereum has proved that if you are in the special class of people (Creators with loads of money lost), you don't matter. Nor do the ideas of what they were supposedly founded with.
This is an implied function that wraps around your full code. This is instantiated if/when core founders are losing money on a function that possibly had a bug in it. This function returns the wrapped function, under the guise of a new blockchain, with invalidations applied to all 'unintentional' side effects of bad or buggy code.
It happened with the DAO, because founders lost too much money. Just be aware, that VIP() can happen to your code, regardless if your implementation is a bug or intentional. Wrong people losing money means VIP() returns successful.
Their encryption by definition, is already backdoored to MS. Game over.
And that's nothing about the stupidity of the TPM itself.
By forcing an escrow key linked to Microsoft and whomever owns the TPM on your computer.
By definition, backdoor keys and hidden users who can access encrypted content is just absolutely, horribly wrong. And there's no way to turn it off... Well, I'm sure someone will say there's 10 regkeys to change that might fix it on a specific version.
Still does nothing regarding the "trust" with the TPM.
Ideally, you want test->stage->prod , with puppet and ansible running on a VM fabric. Changes are made to stage and prod areas of puppet, with configuration management being backed by GIT or SVN or whatever for version control. Puppet manifests can be made and submitted to version control, with a guarantee that if you can code it, you know what you're doing. Ansible's there to run one-off commands, like reloading puppet (default is checkins every 30min)
And to be even more safe, you have hot backups in prod. Anything that runs in a critical environment can have hot backups or otherwise use HAproxy. For small instances, even things like DRBD can be a great help. Even MySQL, Postgres, Mongo and friends all support master/slave or sharding.
Generally, get more machines running the production dataset and tools, so if shit goes down, you have: machines ready to handle load, backup machines able to handle some load, full data backups onsite, and full data backups offsite. And the real ideal is that the data is available on 2 or 3 cloud compute platforms, so absolute worst case scenario occurs and you can spin up VM's on AWS or GCE or Azure.
--Our solution for Mongo is ridiculous, but the best for backing up. The Mongo backup util doesn't guarantee any sort of consistency, so either you lock the whole DB (!) or you have the DB change underneath you while you back it up... So we do LVM snapshots on the filesystem layer and back those up. It's ridiculous that Mongo doesnt have this kind of transactional backup appratus. But we needed time-series data storage. And mongodb was pretty much it.
We suffer from NIH greatly. We end rolling our own stuff because either we don't trust 3rd party stuff, or it doesn't work in our infrastructure. In this case, multiple access locks with GPG is sufficient.
We have a password sheet. You have to be on the VPN(login/password). Then you can log in. Login/Password(diff from above)/2nd password+OTP. Then a password sheet password.
I'm still rooting out passwords from our repo with goobers putting creds in sourcecode (yeah, not config files....grrrrr). But I attack them as I find them. Ive only found 1 root password for a DB in there... and thankfully changed!
Make changes to Stage after doing a "Change Management" process (effectively, document every change you plan to do, so that a average person typing them out would succeed). Test these changes. It's nicer if you have a test suite, but you won't at first.
Once testing is done and considered good, then make changes in accordance to the CM on prod. Make sure everything has a back-out procedure, even if it is "Drive to get backups, and restore". But most of these should be, "Copy config to /root/configs/$service/$date , then proceed to edit the live config". Backing out would entail in restoring the backed-up config.
________________________
Edit: As an addendum, many places too small usually have insufficient, non-existent, or schrodinger-backups. Having a healthy living stage environment does 2 things:
1. You can stage changes so you don't get caught with your pants down on prod, and
2. It is a hot-swap for prod in the case Prod catches fire.
In all likelihood, "All" of prod wouldn't DIAF, but maybe a machine that houses the DB has power issues with their PSU's and fries the motherboard. You at least have a hot machine, even if it's stale data from yesterday's imported snapshot.
[Block of code]
1. 34
2. 17
3. 43
4. 22.5
5. Not listed
____________________This would be a much more clearer way of handling pass by ref/value. 2 of the answers are correct, so this could be reused to ask the other one. If they're being tricky, they can award half-credit for choosing the wrong pass-by-*. And 3 other answers are junk. And this abstracts out any sort of programming neologims or fetishization of $random_language.
I caught 3 "Whoops sorry you missed a weird bug in a specific programming language that you weren't explicitly being tested on". Sure, if I was doing a Python3 quiz, I'd expect those. But this wasn't what the quiz claimed to be.
Turns out, the "fill in the blank" code was easy, got all of them. Along with all the 1st year theory questions.
Primarily, I see ZeroNET as its competitor. And ZeroNET has the bling and the wow factor, but much of the underlying system is.. unfinished. It also requires some heafty frontend with backing DB as well. It seems cobbled on and over-engineered.
IPFS, on the other hand, is clean and clear of its focus. It's simple enough to do as it purports. It works now. It seamlessly works with gateways to allow non-IPFS users to access the network. It's network agnostic: ip4, 6, and whatever else is a protocol addon. And it seems to be on its way to an IETF standard.
Same here. If the truck driver was free to go home, or whatever, sure dont pay them. But traffic jams are in transit between places they are told to go. It doesn't have to be the "fault" of the employer. But the employee is captive, and working, and absolutely should be paid with regards to time.
Lets take a fun game. How about all of Atari 2600?
https://ipfs.io/ipfs/QmacAqRVhJX9eS7YJX1vY3ifFKF9CduDqPEgaCU...
Ok.. This is remote, across all the machines that have that IPFS hash. In other words, its not local.
(in console) ipfs pin add QmacAqRVhJX9eS7YJX1vY3ifFKF9CduDqPEgaCUSa4x5xb
Now its local!
Or lets do something more than a game... How about Node-Red in browser(PageNodes)?
http://ipfs.io/ipfs/QmSCrZUPkqH4gsncsD7tGXPiFpymsbwmywsHXLDh...
EDIT: I had the point in my head, but didn't put it down here. In other words, we already have this technology, and not using buzzword-bingo like "Its the interwebz but with blockchains!". These links are direct proof that it not only exists, but is working right now.
And in reality, making a type of blockchain in IPFS would not be hard. It's an immutable data structure, with append-only characteristics.
And, I also am partial to IPFS, primarily because it feels like a proper IETF-internet scale project. ZeroNET looks prettier, but.. throw away. Again, some subjective feel there, but IPFS feels elegant.
We know a route from X to Y is $miles . Detours happen, but Google is getting to the point of calculating realtime incidents. But time could be fairly compensated, as could the miles on a vehicle.
If you took a way longer route, it's on you. But if you're traffic jammed, it's not your fault, and should fairly be compensated.
You know, that's what Unions are for.
This bit us in our ass with centos 6.8 , when another package required python 2.7... If you install 2.7 directly, your system fails with a thousand cuts. A chroot is needed for that, unfortunately.
Usually, some numbnut "programmer" sets a no-login and a simple password as a secret service account. It invariably is found, and badness ensues.
Whereas login/password is a 1/password_space chance of getting it. It's the combination of a default hidden account and no way to know/change it.
In a side note, I thought about using OnionBalancer, a DB, and Boulder, and making my own OnionCA and talking with the EFF about funding assistance. Frankly, no CA just stinks, and I want to do something about it. I do know that the onionhash is the last 15 characters in the hidden site public key... but there has to be a better way than this.