Win or lose, merit or nonsense the lawyers always win.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
From a quick check of text ISP side retention appears similar to previous failed US attempts. Basically ISP connection "session" level detail.
ISP assigned IP, aggregate data and packet counts, physical connection point..etc. with a uniform minimum retention period... Frankly shit most ISPs keep anyway.
On the Information provider side (websites, email providers) retention appears to be per mail or transaction... an access log or email log file... This is on the hosting side only not ISP side unless of course ISP is hosting.
Thy explicitly seems to not include granular collection on the ISP end... IP flows, DPI/URL type shit.
Last time I was in the market for a mouse I briefly looked at a Razor model when I noticed it required special drivers and "activation" via website... that was the last time I ever bothered looking at any of their products.
The libressl fork was 11 months ago. They managed to add 5 (at a minimum) critical vulnerabilities in the past 11 months?
Probably a *lot* more than that. These are only bugs having been caught thus far.
Jeezus fucking christ.
OpenSSL is currently offering and maintaining four separate release trains for download from the bleeding edge to ancient versions lacking TLS 1.1/1.2 support.
Hard to get excited about DOS/crash shit limited to a new immature branch only a dufus would select for production use... or in other words
I've had the misfortunate to work with 2000, 2005, 2008 and 2008 R2, and 2012, and every single one of them has failed spectacularly, many of them with the same basic issue, that wonderful escalating locks problem, which MS spins as a "performance improvement" much like driving a bus off a cliff improves its performance, and in much the same way.
If lock escalation is your problem then lock escalation isn't the problem.
No. Not really. Microsoft pushes the idea that you don't need to have any clue to use it's products. It helps enable this idea with better novice interfaces. This leads to the problem that you end up with barely trained monkeys having the appearance that they can us Microsoft products.
This is exactly why we recommend Microsoft SQL Server to customers. Barely trained monkeys is more realistic than expecting a trained DBA on staff.
I think Microsoft has the only RDBMS that ever had a genuine viral exploit in the wild.
So what is the relevance some dozen years later? By all measures SQL Server has had a good security record compared with competing products. Check public CVE data for each product and make an informed decision.
Left a test Oracle server running overnight accidentally a number of years ago it had been owned by time I got in the next day...cherry picking is worthless... everyone can find an example supporting their presuppositions.
So LibreSSL had already avoided 9 of these issues as a result of their code cleanup.
5 of them at least a result of forking before relevant code/feature existed.
CVE-2015-0208, CVE-2015-0207, CVE-2015-0290, CVE-2015-0285 and CVE-2015-0291
This includes all CVEs labelled as high severity. This is just another reminder to use LibreSSL.
I think having other forks and more people working a project is ultimately great for everyone. The tit-for-tat elitism and misleading hyperbole is not productive.
data to make to a solution that makes sense in that context?
The problem with rules is that there is always exceptions. i.e. Sometimes accelerating will avoid the accident!
Is the program smart enough to widen the search space and consider alternative solutions?
The rest of your post is interesting.
Assuming turbo-boost is inoperable there are only so many things we can do. Go faster, slower or same while going straight, left or right.
For a computer doing some vector arithmetic brute force style across all possible reactions seems on its face to be quite trivial next to challenge of developing a valid model of the system/environment in the first place.
I think only blind people miss that part and falsely believe you have to create a Microsoft account.
No matter how "obscure" some idiot like GP claims it to be
It is clearly intentionally deceptive. There is no excuse for this behavior from a corporation who expects people to trust them.
it's still far better than what Google does, forcing users to create a Google account with no option for a local account on Android or Chrome OS.
Better than what Microsoft does when you refuse to set an account on a Windows Phone device. At least I can still use an Android device and install software on it without having a Google account.
Find a smaller outfit
This is a real problem and I don't mean to minimize it. But weak encryption is infinitely better than none,
Not when people think "It's encrypted".
Sometimes it is much better to know something is insecure and behave accordingly than to depend on a lie and get burned.
VPN technology especially is particularly abysmal everywhere I go customers using PPTP, some form of challenge-response authentication over the clear or over shared keys or using EAP methods without properly verifying trust chains. At least with secure websites we have security checkers like Qualsys... if you were to run that same scanner on the TLS channel protecting authentication it would universally fail. Even the CBC record splitting hack is explicitly disabled for backwards compatibility. Have never been on site where VPNs were deployed (both client and server configuration) properly.
many wholly unencrypted connections that are happening this very moment. I think we should prioritize getting all connections everywhere encrypted somehow.
When normal people hear the word "encrypted" what they actually hear is "secure". Nobody understands what "encrypted but insecure" means.
Lies can be worse than doing nothing. Much better to do it right in my opinion.
If a group, race or gender 'x' can be statistically shown to be more 'y' or less 'z' then it is ok to use generalities about a group to make judgments about individuals?
This is very same error in judgment routinely used by racists and crackpots to justify all kinds of craziness.
What would it take for a connected device, whether a wallet or a smoke detector, to gain mass appeal?
It will take a few billion more in marketing campaigns to get people to care.
Once they do you have a short while until your customers begin notice how worthless and or dangerous their purchase turned out to be.
My kids, young and unencumbered by tradition prefer the LED lights.
You can get any color temp you want with LEDs same as old fashion bulbs. If your kids prefer a higher color temperature this may only indicate they prefer a higher temp bulb rather than a useful comparison between LED and Incandescent. If the test isn't apples to apples its worthless.
So will everyone else rather soon, as we slowly transition to whiter more sunlight-like hues that are now possible with LEDs.
No, different people have different color temperature preferences. This isn't changing anytime in the foreseeable future. Huge markets for both high and low temperature bulbs not going away anytime soon. LED changes nothing.
I would also recommend getting some familiarity with the PCI DSS standard.
PCI DSS is full of bad advice. Codifying specific technical measures, going off the deep end with dual control and unrealistic password management begging 4 proliferation of sticky notes and even promulgating dangerous advice on application of one way algorithms with inherently low entropy data.
It reads like a book of common wisdom written by someone who read security for dummies and now thinks they know everything.
Security standards for specific purposes tend to be so soaked in political calculations they rarely make good templates if you care about actual outcomes more than your desire to CYA or check a box.