Slashdot videos: Now with more Slashdot!
FFS, doesn't anyone do any research before posting stories? 60 seconds of research would turn up the Wikipedia entry on End-to-end audible voting systems. The problem of being able to verify that your vote is recorded as you intended without revealing the actual content of your vote has been solved by several teams. The ones that seem to have the best handle on things are Scantegrity, Pret-a-Voter, and Punchscan (the predecessor of Scantegrity) .
Using Bitcoin (which in fact has anti-anonymity properties) as an engine for voting is like attaching a tractor to a horse carriage. It may get you where you want to go, but it's nothing like a proper motor vehicle.
The evidence here is really, really weak. The connection is tenuous enough and the original pool of possible suspects via their methodology is large enough that I sure as heck wouldn't rule out a connection via random chance. Until we get better evidence, this isn't worth very much.
Norse Security says as much in The Fine Article:
Stammberger was careful to note that his company's findings are hardly conclusive, and may just add wrinkles to an already wrinkled picture of what happened at Sony Pictures. He said Norse employees will be briefing the FBI on Monday about their findings.
"They're the investigators," Stammberger said. "We're going to show them our data and where it points us. As far as whether it is proof that would stand up in a court of law? That's not our job to determine, it is theirs," he said of the FBI.
Geez how the press gets this sort of thing so wrong. It's not a tank, it's an Infantry Fighting Vehicle (IFV). It's lightly armored against small arms and small-bore auto-cannon rounds, not against ATGMs, tank main guns, or RPGs.
The weight at 34 tonnes is much less than that of any current front-line tank (according to Wikipedia the Challenger 2 is 62.5 tonnes, almost double the Scout SV). It is a lot heavier than most current IFV's (e.g., the German Marder at 28 tonnes or BMP-3 at 18.7 tonnes), but that may not be such a good thing. It makes strategic mobility more of a problem and ensures that the Scout SV can't swim across rivers by itself.
Some reporter just cut and pasted from the press release. Feh!
My son took the course last year as a senior in high school via iTunesU.
It's also available on EdX.
Heck, I took it way back thirty-odd years ago.
Also, here's a link to the original article in the Harvard Crimson:
In chronological order looking forward:
MacTech Boot Camps - http://www.mactech.com/bootcam...
Small, local, inexpensive. Check to see if there's one close to you.
MacTech Conference - http://www.mactech.com/confere...
Larger, both sysadmin and developer tracks
MacIT - http://www.macitconf.com/
Larger, multiple tracks and levels of knowledge
WWDC - https://developer.apple.com/ww...
The granddaddy of them all, but next to impossible to get into these days. Mostly developer focused. May not be useful if you don't already have a deep knowledge base.
MacAdmins - http://macadmins.psu.edu/
The most education-focused of the conferences. Very knowledgeable presenters.
FWIW, I've been a presenter at MacTech Boot Camps, MacIT, and WWDC.
See the commentary at the top of the page from this link:
"In our security investigation, we have found no evidence that any of the content you store in Evernote was accessed, changed or lost. We also have no evidence that any payment information for Evernote Premium or Evernote Business customers was accessed.
"The investigation has shown, however, that the individual(s) responsible were able to gain access to Evernote user information, which includes usernames, email addresses associated with Evernote accounts and encrypted passwords. Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.)"
No indication as to the hashing mechanism — is it a simple, easily brute forced MD-5 or is it a harder, more secure PBKDF2, Bcrypt, or Scrypt with lots of rounds? Anyway, Evernote has reset the passwords of all of the affected users."
Link to Original Source
Lots of good advice so far, but one more item -- since your father has turned sysadmin tasks over to you, once you wipe and re-install, set up his account on the computer so that it is a restricted user account, not an admin account. If he isn't doing sysadmin tasks then he doesn't need the privs and this limits the amount of damage that a scammer can do to the computer. (Although getting his SSN and other info is still really bad.)
I'm a former Apple engineer, current independent consultant, so I'm not going to address the Android side. That's a lot more complicated -- I'll stick with talking about the iOS info that I know about.
That said, wow, there's a lot of snarky comments but not a lot of information posted.
iOS has full-device hardware encryption built-in on the iPhone 3GS and later, activated as soon as you set up a passcode. This top-level encryption layer is for quick device wipes, not for data protection. Each user data file is then encrypted on top of that using its own unique key, then set into a protection class by the app developer:
- Complete Protection - decrypted only when the device is unlocked; file key is removed from memory when the device is locked.
- Protected Unless Open - decrypted when the device is unlocked; if file is open when the device locks, the file stays open/decrypted.
- Protected Until First User Authentication - decrypted on first unlock, stays decrypted until reboot
- No Protection - file system encryption only; no per-file encryption key
Apple has really been on developers cases to tighten down the data protection classes for their apps on iOS.
In addition, iOS has a huge number of remote management options. Apple provides a basic management tool called Profile Manager in Lion Server, and there are third-party Mobile Device Managers (MDMs) that take the basics and go even further. You can force complex passcodes, pre-configure e-mail accounts, restrict usage of features, and so on. The enterpriseios.com site has a pretty complete listing.
One of the cool things about using iOS MDM is that all of the configuration profiles are tied to the management profile that gets installed when the device is first enrolled with the MDM. If you're in a BYOD situation and a user leaves on bad terms, the IT department can retract the management profile, which automatically retracts all of the other configuration profiles. This will delete corporate e-mail accounts, remove in-house apps (and their data!), take away VPN and 802.1X access, and so on, without erasing the person's device entirely. All of the pictures the person took are still there, not blown away as they would be after a complete device wipe.
Anyway, a few links that may help you out:
http://consultants.apple.com/index.php - look for consultants with the Mobility specialization
https://help.apple.com/advancedserveradmin/mac/10.7/ - go into "Manage Users" --> "Profile Manager" on the right
Hope this helps.
As part of the settlement, Glik agreed to withdraw his appeal to the Community Ombudsman Oversight Panel. He had complained about the Internal Affairs Division's investigation of his complaint and the way they treated him. IAD officers made fun of Glik for filing the complaint, telling him his only remedy was filing a civil lawsuit. After the City spent years in court defending the officers' arrest of Glik as constitutional and reasonable, IAD reversed course after the First Circuit ruling and disciplined two of the officers for using "unreasonable judgment" in arresting Glik.
Link to Original Source
Link to Original Source
This is exactly the design scenario for Podcast Publisher and Podcast Library.
While it can take advantage of a whole cluster of servers, it can also run (albeit more slowly) on a single Core i7 Mini Server. For more detailed docs, see:
It's in use at lots of universities and some K-12 schools.
Hope this helps.
This is just going through the motions. DigiNotar has been dead since August 30, when Google, Mozilla, and Microsoft all revoked trust in their certificates. Anyone with at least two brain cells (which seems to exclude a large number of managers, unfortunately) could see the writing on the wall. No one would ever buy a new DigiNotar certificate, since it would always pop up a scary warning to the user in a web browser. Why bother with buying a certificate from DigiNotar and dealing with the resulting end-user support issues, when you can buy from someone else and not have to deal with the problem?
More interesting to me is what will happen to DigiNotar's corporate parent, Vasco Data Security? The purchase of DigiNotar is relatively recent (January 10, 2011), so it's not clear how much influence Vasco's management had over DigiNotar's operations. At the very least, Vasco is going to need to pay for an audit of its own systems to reassure its direct customers.
APCO 25 doesn't seem to be very well thought through. Easily jammed at multiple levels and vulnerable in many ways.