...and has been explained to me by coworkers from these regions, there is now a period of reverse-discrimination in India.
University admission seats are now reserved in quantity for lower castes who were previously unable to obtain an education, as are jobs upon graduation. This leaves fewer options for members of the upper castes of moderate means, leading to their desire to leave the country.
India's academic ratings are not representative of the people who come to our shores for this reason.
Verizon is notorious for locking phones on their network, preventing updates and general intransigence in the face of crumbling Android security.
The FTC should make an example of Verizon - key escrow that opens for any phone that reaches six months without a security patch.
Verizon has demonstrated that control is more important than security. The public should demonstrate, through the regulatory actions of the FTC, that security is more important than profits.
To reiterate, when a vendor abandons support for a critical communications device, all unlock codes should be divulged by legal requirement. That solves the problem for everybody.
Within the last year I have placed two critical 911 calls. I also have family members who have had heart bypass surgery. Phones can be critical, sycophantic beratement aside.
I have NEVER seen a Motorola phone for Verizon that is unlocked. I started using them after the Google buyout. The unlock website refuses to alter them.
Yes, a class action would also be great!
Any phone vendor who cuts support for a model should be REQUIRED to open the platform for 3rd-party maintenance. A phone is not a general purpose computer, and there should be special rules for it.
No exceptions. A phone is a critical communications device, and if the OEM won't supply critical upgrades, then they must allow others to do so.
DMCA exceptions should be established, and vendors should not be allowed to sell phones within the U.S. without providing all required unlock keys into an escrow. Upon 6 months of patch inactivity, the keys go public.
...even if the main database servers are down with a bad case of cryptolocker?...and the backups have been quietly copying from/to/dev/null for the last three months?
...and Toyota settled with utmost haste after they were found guilty.
http://www.safetyresearch.net/...
Software like this CANNOT be connected to larger networks safely.
I loaded Opera Mini on a Jellybean device, and tested it against the best-known SSL/TLS Scanner.
Initial tests passed with flying colors, and indicated that I was using the "Presto" rendering engine, which routes traffic through Opera's server farm for compression.
However, after I reduced the "data savings" parameter in settings from "extreme" to "high," Opera Mini then FAILS with flying colors, because it's using the Jellybean Webkit directly (that lacks TLS1.2, bundles bad ciphers, etc.).
EnterpriseDB bundles a PL/SQL implementation that is advertised as compatible with Oracle's procedural SQL language (similar to ADA). This component is NOT open-source.
Well, of course, Microsoft could never use a sandbox in production code for the Windows desktop, because ease-of-use and compatibility would be compromised. Sandboxes are just for servers.
Privilege separation and sandboxing are well-tested mitigation techniques that allow OpenBSD to assert "Only two remote holes in the default install, in a heck of a long time!" - this security record is far, far superior to the Windows OS and the virus scanners that run atop it.
What Microsoft still fails to grasp, even after Gates' force majeur with the XP-SP2 security redesign, is that all applications should default to a strong sandbox. When a developer pushes code outside the sandbox, it should trigger more aggressive audits prior to listing in the Windows store, and user warnings of increasing severity upon installation.
The pertinent question for developers and administrators, especially with regards to network-facing services, is "how strong can we build the cage, and how little can we let out?" Until OS-designers build from this focus, the security tsunami will continue.
Slashdot Mirror
...and has been explained to me by coworkers from these regions, there is now a period of reverse-discrimination in India.
University admission seats are now reserved in quantity for lower castes who were previously unable to obtain an education, as are jobs upon graduation. This leaves fewer options for members of the upper castes of moderate means, leading to their desire to leave the country.
India's academic ratings are not representative of the people who come to our shores for this reason.
Verizon is notorious for locking phones on their network, preventing updates and general intransigence in the face of crumbling Android security.
The FTC should make an example of Verizon - key escrow that opens for any phone that reaches six months without a security patch.
Verizon has demonstrated that control is more important than security. The public should demonstrate, through the regulatory actions of the FTC, that security is more important than profits.
Easier to outlaw the practice.
To reiterate, when a vendor abandons support for a critical communications device, all unlock codes should be divulged by legal requirement. That solves the problem for everybody.
So we should just learn to like neighborhood gunfire, and police need no help from us. 911 services are irrelevant and should be decommissioned.
There were over a hundred WebKit security updates last year. How many made it to the iPhone 3? https://blogs.gnome.org/mcatan...
Let me know when you get your microwave patched to dial 911. I hope that works out for you.
Everything on Verizon is locked AFAIK.
Within the last year I have placed two critical 911 calls. I also have family members who have had heart bypass surgery. Phones can be critical, sycophantic beratement aside.
I have NEVER seen a Motorola phone for Verizon that is unlocked. I started using them after the Google buyout. The unlock website refuses to alter them. Yes, a class action would also be great!
According to wikipedia, Apple took this phone out behind the woodshed in 2012.
Any phone vendor who cuts support for a model should be REQUIRED to open the platform for 3rd-party maintenance. A phone is not a general purpose computer, and there should be special rules for it.
No exceptions. A phone is a critical communications device, and if the OEM won't supply critical upgrades, then they must allow others to do so.
DMCA exceptions should be established, and vendors should not be allowed to sell phones within the U.S. without providing all required unlock keys into an escrow. Upon 6 months of patch inactivity, the keys go public.
...even if the main database servers are down with a bad case of cryptolocker? ...and the backups have been quietly copying from/to /dev/null for the last three months?
...and Toyota settled with utmost haste after they were found guilty. http://www.safetyresearch.net/... Software like this CANNOT be connected to larger networks safely.
...are not voice calls or text messages: it's search, and it shows.
Where is ublock for Chrome on Android? That says all you need to know about Google's intentions on mobile.
I was actually testing several dozen Android browsers for a project. No, I'd never use a browser engaging in this (Amazon).
I loaded Opera Mini on a Jellybean device, and tested it against the best-known SSL/TLS Scanner.
Initial tests passed with flying colors, and indicated that I was using the "Presto" rendering engine, which routes traffic through Opera's server farm for compression.
However, after I reduced the "data savings" parameter in settings from "extreme" to "high," Opera Mini then FAILS with flying colors, because it's using the Jellybean Webkit directly (that lacks TLS1.2, bundles bad ciphers, etc.).
This is deceptive. Don't install this product.
EnterpriseDB bundles a PL/SQL implementation that is advertised as compatible with Oracle's procedural SQL language (similar to ADA). This component is NOT open-source.
http://www.enterprisedb.com/compatibility-explained
IBM bundles the same PL/SQL emulation code in DB2.
...you mean that we likely already have one.
http://www.space.com/30245-x37b-military-space-plane-100-days.html
If I sent you my RSA public.key file several months ago, then you could use it to do this:
#!/bin/sh
/tmp/skey
/tmp/skey | openssl base64
echo +++
#build a session key
openssl rand -base64 48 -out
#encrypt the session key with RSA
openssl rsautl -encrypt -pubin -inkey public.key -in
#encrypt files with AES
for f
do openssl enc -aes-128-cbc -salt -a -e -pass "file:/tmp/skey" -in "${f}"; echo +++:
done
Mail me the output, and I'll get the original cleartext back. No key exchange.
My local paper recently ran an article on these abuses.
“We the Prisoners”: The Demise of the Fourth Amendment
Well, of course, Microsoft could never use a sandbox in production code for the Windows desktop, because ease-of-use and compatibility would be compromised. Sandboxes are just for servers.
Privilege separation and sandboxing are well-tested mitigation techniques that allow OpenBSD to assert "Only two remote holes in the default install, in a heck of a long time!" - this security record is far, far superior to the Windows OS and the virus scanners that run atop it.
What Microsoft still fails to grasp, even after Gates' force majeur with the XP-SP2 security redesign, is that all applications should default to a strong sandbox. When a developer pushes code outside the sandbox, it should trigger more aggressive audits prior to listing in the Windows store, and user warnings of increasing severity upon installation.
The pertinent question for developers and administrators, especially with regards to network-facing services, is "how strong can we build the cage, and how little can we let out?" Until OS-designers build from this focus, the security tsunami will continue.
The recent "Subway" supercomputer cluster is supposedly based on an Alpha 21164 design. https://en.m.wikipedia.org/wik...
Use shred -n 7 /dev/sda - dd is hardly sufficient, especially if my finances are involved.
NAME shred - overwrite a file to hide its contents, and optionally delete it
/dev/hda, and those files usually should not be removed. The optional
/etc/fstab file, as documented in the mount man page (man mount).
SYNOPSIS shred [OPTION]... FILE...
DESCRIPTION
Overwrite the specified FILE(s) repeatedly, in order to make it harder
for even very expensive hardware probing to recover the data.
Mandatory arguments to long options are mandatory for short options
too.
-f, --force change permissions to allow writing if necessary
-n, --iterations=N overwrite N times instead of the default (3)
--random-source=FILE get random bytes from FILE
-s, --size=N
shred this many bytes (suffixes like K, M, G accepted)
-u, --remove[=HOW]
truncate and remove file after overwriting; See below
-v, --verbose
show progress
-x, --exact
do not round file sizes up to the next full block;
this is the default for non-regular files
-z, --zero
add a final overwrite with zeros to hide shredding
--help display this help and exit
--version
output version information and exit
If FILE is -, shred standard output.
Delete FILE(s) if --remove (-u) is specified. The default is not to
remove the files because it is common to operate on device files like
HOW parameter indicates how to remove a directory entry: 'unlink' =>
use a standard unlink call. 'wipe' => also first obfuscate bytes in
the name. 'wipesync' => also sync each obfuscated byte to disk. The
default mode is 'wipesync', but note it can be expensive.
CAUTION: Note that shred relies on a very important assumption: that
the file system overwrites data in place. This is the traditional way
to do things, but many modern file system designs do not satisfy this
assumption. The following are examples of file systems on which shred
is not effective, or is not guaranteed to be effective in all file sys
tem modes:
* log-structured or journaled file systems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
* file systems that write redundant data and carry on even if some
writes fail, such as RAID-based file systems
* file systems that make snapshots, such as Network Appliance's NFS
server
* file systems that cache in temporary locations, such as NFS version 3
clients
* compressed file systems
In the case of ext3 file systems, the above disclaimer applies (and
shred is thus of limited effectiveness) only in data=journal mode,
which journals file data in addition to just metadata. In both the
data=ordered (default) and data=writeback modes, shred works as usual.
Ext3 journaling modes can be changed by adding the data=something
option to the mount options for a particular file system in the
In addition, file system backups and remote mirrors may contain copies
of the file that cannot be removed, and that will allow a shredded file
to be recovered later.
GNU coreutils online help:
Report shred translation bugs to
Packaged by Cygwin (8.23-4) Copyright © 2014 Free Software Foundation,
Inc. License GPLv3+: GNU GPL version 3 or later
. This is free software: you are
free to change and redistribute it. There is NO WARRANTY, to the
extent permitted by law.
AUTHOR Written by Colin Plumb.