http://tech.slashdot.org/comments.pl?sid=23032388&cid=63785372

It's Crap. My Adaptations... (Score:2)
by Voyager529 ( 1363959 ) Alter Relationship on Mon Aug 21, '23 11:22 AM (#63785372)

0. Use Rufus (http://rufus.ie/en/) to create a bootable Windows 11 installer that handles steps 1-3 for you if desired; run through the Windows install process.
1. During the initial run, hit Shift+F10, then type "oobe\bypassnro". This will cause a reboot. Also, disconnect from the internet.
2. During the second run, state that you 'don't have internet', and you want to 'continue with a limited setup'. This will allow you to set up a local account.
3. During the customization screen, select 'no' to all of the options.
4. When you get to a desktop, open Edge. Each of the initial setup screens has a low-contrast close button; use them. Go to www.ninite.com and download Chrome/Firefox, maybe 7zip and Notepad++ or whatever other things are needed (.net frameworks are also helpful if running older software).
Open Chrome/Firefox and go here: http://community.spiceworks.com/scripts/show_download/4378-windows-10-decrapifier-18xx-19xx-2xxx . It works on Windows 11 and still gets rid of most of the core annoyances and appy-apps, needless scheduled tasks, and so on. Reboot.
5. Download this awesome application, run it as admin, and click through the desired checkboxes: http://www.w10privacy.de/english-home/ .
6. You'll probably need to set Windows Defender to exclude the Hosts File from detection; it'll reset it by default based on the telemetry blocking from step 5 if you implemented it.
7. Go to Settings->Apps->Default Apps and set your preferred default browser and PDF reader.
8. If you're adventurous and loathe the Windows 11 Taskbar and Start Menu, install ExplorerPatcher: http://github.com/valinet/ExplorerPatcher . Classic Shell and OpenShell also work to bring back a useful, ad-free start menu. NOTE: some recent Windows Updates have caused issues with EP; it's a bit of a cat-and-mouse game that is fixed with an uninstall/reinstall, but it is a pain to resolve if the need arises.

It's absolutely abhorrent that it requires third party utilities and shell scripts to make Windows 11 vaguely tolerable...but this config has been viable for me thus far.

When someone says "Black lives matter" I generally assume good faith* and assume they really mean something like:

"All lives matter, but recent events show that at least a few people think that some lives - specifically Black lives - matter less than others. Rather than taking the time to say 'Hey dude, yes, you Mr. Cop who shot a Black man without a good reason, you need to treat Black people with the same respect as non-Black people' I'm going to use the much shorter, fits-on-a-bumper-sticker phrase 'Black Lives Matter'".

* As with just about all human behavior, there will be the rare case where the assumption of good faith was not warranted. But this is rare.

Roe v. Wade was recently overturned in the United States. This means abortion laws are pretty much left up to the individual states.

Some states outlaw abortions and do not provide exceptions when the pregnancy is the result of rape.

Here's a thought: Should a rape victim who becomes pregnant be entitled to sue the rapist for "9 months of involuntary servitude" under anti-slavery laws?

If the rapist cannot pay or is unknown, should the victim be allowed to sue the state for compensation under anti-slavery laws for the several months between the time the victim would have had the opportunity to end the pregnancy under Roe v. Wade and the actual end of the pregnancy?

--

Notice that I am not advocating requiring that states allow abortion for rape victims. Weighing the morality of abortion vs. the morality of slavery is a discussion for another time. I AM advocating that enforced pregnancy be seen as a form of slavery and that all parties that contribute to this condition should be held financially responsible for the damages inherent in being enslaved.

--

I have turned comments off on purpose. Slashdot is not the forum for this type of discussion.

Instead, I invite everyone who reads this to think about it and discuss it with their loved ones, their religious leaders, and their political leaders.

[If this hits the Slashdot Firehose, my apologies, it is not intended as a submission. Please don't vote it up or down, just let it scroll off the screen over time.]

In this day and age where fake pictures and videos are so good that anyone can cast serious doubt on a real picture or video by calling it "fake," should cameras include the option to create a "digital signature" or similar authentication?

If I were a journalist or even a citizen-journalist, I'd want to have a time-stamped, possibly location-stamped digital signature on every photo, video, and audio-recording I made in the course of my work.

I'd want to get these signatures or at least a "signature of today's signatures" published in a non-repudiate-able way ASAP, so if I later publish my photo I or my employer could quickly prove it was authentic.

If the image is likely to be cropped before publication, well, that can be handled too, by having the camera also store "standard crops" of every photo along with their respective signatures. A standard crop might be something like "divide the image into 5-10 strips on the narrow dimension and similar-sized evenly-spaced strips on the wider dimension, then treat each 2x2 rectangle as a "standard crop," saving it and its digital signature in addition to the main image.

For video, where the final published product is likely to be a snippet, still/screen-shot, or even a crop, do something similar with a still frame a few times a second. For the audio track, save overlapping staggered two-second snippets and sign each of them. This would be in addition to the signature on the whole video.

The important thing is that the signatures can be published in a non-repudiate-able way within minutes or hours of the photo or video being taken, even before a decision to publish the photo or not is ever made. This way I or my employer can prove a photo or at least the "standard crops" of it and "standard snippets of audio" in it have not been altered since the time the signature was published. For most photos where the motivation or ability to create a fake didn't exist at the time the photo or video was taken, this should deter anyone from screaming "fake, fake" since they know everyone else will know the photo, video, or audio is legit.

There are some obvious costs and other risks:

* This is a lot of work and will take a lot of energy, especially if it is done in real-time or very-near-real-time. At best this will drain the battery. There could also be thermal issues and issues with media that can't be written to fast or with many concurrent writes. This problem will take care of itself as technology improves.

* Assuming the camera's private key isn't in something like Apple's secure enclave, this will require a way to change and manage private keys. If the key is "baked in" to the device, it may reduce the resale value of a camera, since the new buyer's photos will have the same signature as previous users' photos. This may be a non-issue if the camera is used by its original owner until it is obsolete.

* This technology can be abused by authoritarian regimes by requiring it in all cameras. What else is new.

* If it becomes standard in smartphones, it can be abused by advertisers and others. Again, what else is new.

* If it becomes standard in cameras and "on by default," people who turn it off may be considered "suspicious" or "paranoid." Again, what else is new.

Sig as of 2025-01-31

"Things happen in space, sometimes in a spaceship." -A. Cunningham, 2025

Source: http://web.archive.org/web/20250128174748/http://arstechnica.com/culture/2025/01/theres-not-much-for-anyone-to-like-in-the-star-trek-section-31-movie/

Thereâ(TM)s not much for anyone to like in the Star Trek: Section 31 movie

Even for fans of Discovery or franchise completists, this one is hard to watch.

Andrew Cunningham â" Jan 28, 2025 11:26 AM



Sig as of 2024-11-11

Beam me sideways, Scotty; nobody here knows which way is up.

Sig as of 2024-07-14

Votes not violence - disagree agreeably

Sig as of 2024-03-17

Former president: "In some cases, [migrants are] not people"
MIB: "Time to re-neuralize him." Sig as of 2023-07-19 Autocratic capture - DO NOT WANT Sig as of 2023-03-23 Actual sig due to space limits and automatic formatting: "... but the people magnified them, to make great or embiggen ..." - C. A. Ward, 1884 Intended sig: "... but the people magnified them, to make great or embiggen, if we may invent an English parallel as ugly." - C. A. Ward, 1884, via: Notes and Queries. Oxford University Press. p. 135. Sig as of 2022-11-05 This signature intentionally left blank. Sig as of 2022-07-02 Is enforced pregnancy after rape a form of slavery? Sig as of 2021-04-16: Assume people are morally better than they used to be until proven otherwise, pity the person who is not. Sig as of 2020-05-28: In Soviet Russia, [MY] MASK PROTECTS YOU! Sig as of 2019-08-13: In Defense of ACs (./ 1999) Note: Expanded URL is http://news.slashdot.org/story/99/01/25/1713206/in-defense-of-anonymous-cowards Past sigs: http://slashdot.org/journal/1186793/sig-update-2018-02-17-was-sig-update-2014-08-14 http://slashdot.org/journal/281635/signature-line-update-2012-04-23 http://slashdot.org/journal/94557/my-sig-lines

Note: Based on a response to this spam by a spammer whose only submissions were 3 recent submissions spamming basically the same thing.

--cut here--
Subject: How to abuse /. to promote things

New to Slashdot? Heard it's a great place to promote your product or idea? Well, maybe. Before abusing /. for personal gain, take time to read the advice below. Not following it will lead ot frustration. Following it *may* lead to success in abusing /. but more likely, it will lead to enlightenment.

1) Is the thing you want to spam technical in nature? if not, give up, your submission will not be accepted by a non-established editor if it's even remotely promotional. Yes, there are non-technical items that make the front page, but these are generally news items. In the rare case that a non-technical promotional item makes the front page, it's because it's already all over the news, it doesn't need your help to promote it.

2) Is your advertising time-sensitive? If you can't wait a few months to build up a good reputation, forget it, as a new submitter, your submission will not be accepted if it's even remotely promotional.

Still want to give this a go?

3) Take the time and effort to become an established editor with a "good karma." This takes months and dozens of qualitity replies. If you are at all a decent human being, at the end of this stage you will realize spamming Slashdot is bad. You may have abandoned your goal of spamming Slashdot, but you may regain your humanity in the process. It's a win-win for everyone, well, everyone except whoever wanted you to spam.

Still want to spam Slashdot? Is the item you want to spam technical? Is there still a market for it?

4) Find an article about it on a non-spammy reputable site. Mainstream news sites are best, but NON-BIASED, WELL-RESPECTED tech-related sites MAY be okay.

5) Is the article in any way promotional? Don't use it. If it's promotional it *might* be accepted but people will see your submission in your history and people will screen your future submissions more carefully.

6) Is the writer of the article known for being a "shill" for this or any other product, service, or idea? Don't use it, for the same reason as #5.

Okay, if you've reached this point, you've taken the time to earn a good /. reputation, you've found a source that is likely to be acceptable.

Now comes the hard part: Writing a summary that does not sound promotional.

If you can do that *despite* being bent on abusing /. for personal gain, congratulations, you've mastered the art of blending in with legitimate contributors. Your submission may actually be accepted.

If it is not, do not re-submit any other articles on the same topic for several months and not until you've posted several dozen quality replies during that time. If you get in a hurry, people will figure out you are a spammer and your account may lose its reputation.

That's the long-and-drawn out way to abuse Slashdot to promote things.

There's a much shorter way: DON'T.

[Note: This is NOT a submission for the "front page" so if it shows up in Firehose, please down-vote it. Comments are welcome. The purpose of making this public is to get people to start thinking about it for areas that are under-served by wireless internet and to make it clear that the general idea is too obvious to be patent-able, or at least it would be for any reasonable definition of "obvious." I'm not a lawyer and I'm very well aware that in patent law, the definition of "obvious" is sometimes neither obvious nor reasonable.]

IP over SMS

IP over SMS should be relatively trivial to implement.

Simply take data from higher in the stack, prepend headers and footers, and divide it into packets of 140 bytes packets, leaving room for per-packet headers and footers as well. The SMS source and data destination are transmitted with each packet seperately so they do not need to be in the data stream.

The following is just one of many obvious examples of how it can be done, it may not be the best implementation.
Other implementations may include things like encryption, using keys that were previously exchanged using a reliable method, such as by photographing a bar code that contains the other endpoint's public key, then sending the other party a one-time number encrypted with that key.

Example: incoming data from an IP layer above:

Note: For each SMS message sent, the SMS external header would contain the same information as any other SMS packet, including the source number and destination number. From the point of view of the SMS network the data below, including the SMS internal header in each SMS message, is just another text message or series of text messages.

IP header: From: 1.1.1.1 To: 2.2.2.2 Data: Forscore and seven years ago ... November 19, 1863

Divide this into several packets:

SMS internal header:
MAXMSGS, maximum messages at one time: variable length, 0 (1 bit) or starts with 1 and ends with 0: Take this number, add 2, and multiply by 128. 0=(0+2) * 128 = 256 simultaneous messages between SMS points A and B, 10 = (2+2)*128=512, 110=(6+2)*128=1024, etc.
Msg number (variable length, 1+ preceeding, with rollover). This allows up to MAXMSGS different communications to be going on between point A and point B at the same time.
Packet count within a message: (8, 16, 24, etc. bits) up to 6 bits followed by 00, OR leads with 0 followed by 6 bits followed by 1 followed by the same as many times as needed to hold packet count within message.
Number of packets left in message: same format as packet count.
Packet size 1 bit (0) OR 12 bits: 0 if the this SMS packet is "full," i.e. all 140 bytes are used, otherwise 1 followed by the number of BITS in this packet, including headers.
Data:
Remaining bits in SMS packet are devoted to data. Unused bits are not sent.

When this is practical:
Any time high-latency communication can be tolerated and a more efficient network is not available, this is practical.
This would be common in parts of the world where reliable internet is spotty or much more expensive than SMS, or in disaster situations where SMS may be much more reliable than other forms of Internet service.
However, practical does not imply useful.

Examples of when this is useful, given that it is practical in a given situation:

Group SMS, picture SMS, and other messages typically delivered over methods other than SMS (e.g. Apple's iMessages).
Email.
"Pushed" data such as weather, traffic, stock reports, banking alerts.
Exchanging authentication tokens or other small amounts of information.
Web browsing with a caching web browsing (compare with HoTMetaL, a circa-1993 caching web browser used for dialup), assuming the user is willing to put up with "page loading, check back in 15 minutes" messages, and assuming web pages that target this audience are designed to be used in an "ultra lightweight" mode.

Typical communication will be over UDP rather than TCP, with applications that are "high latency aware" managing things such as re-sending of data, etc.
The UDP layer or the application layer may manage encryption.

Patentability:

Most methods which is not unnecessarily convoluted would be obvious to anyone skilled in the art, and therefore it should not be patentable.
There may be some patent potential for some small efficiencies, but the difference between the "best engineered" implementation and a slightly-less efficient obvious one would be minimal and the benefit to using a non-patent-encumbered implementation far exceeds any small technical benefit of an optimized implementation in most cases.

A test - but not the only test - of obviousness would be to present the problem of "design an efficient method of solving the problem" to a large number of teams (more than 1000) of people trained in the field but who come from otherwise different backgrounds, and see if any of the solutions they arrived at are anywhere close to the solution you are seeking a patent on. If they are, it's probably obvious. The more teams that come up with a solution similar to yours, the more obvious it likely is. Include solutions the teams rejected for whatever reason, or solutions that they would obviously have found but for the fact that they rejected a particular line of inquiry because they thought it was a dead end or would lead to an inferior result.

**PRE-DRAFT**
4/27/2018
davidwr

Using paper to make a "secure vault" for key-escrow systems

Definitions:

Key-escrow system: A system in which a 3rd party holds backdoor "keys" to many locked "things" - e.g. phones, computer accounts, etc.

Secure vault: A system in which the backdoor keys are effectively protected against unauthorized access.

Summary:

Public/private key pairs are generated.
Private keys are encrypted using a master key.
The encrypted private keys are split into two parts.
Each part is printed out and stored in a separate locked box.

Variations:
Encrypted keys are split into more than two parts.
The master key changes periodically, e.g. every 1000 keys or every week.
Multiple copies of printouts can be made to provide redundancy. If this is done, any verification system needs to make sure the multiple copies are in fact the same.

Example:

System with one master key and with the encrypted private key split into two parts, with an automated verification system.
Each part has the last 50% of the generated public key, a serial number, and a time-stamp, and the serial number of the generating machine, which together serve as a label.

The system consists of two systems: A generator system an an automation system.

The generation system:

Input is the master key, typically the public key of a public/private key pair.
Output consists of three printouts, 1 of which is public and 2 of which are private.
The public printout consists of the label described above plus the generated public key.
Private printout #1 consists of the label described above plus an "part number" indicating "part 1 of 2" and the first 50% of the encrypted private key.
Private printout #2 consists of the label described above plus an "part number" indicating "part 2 of 2" and the second 50% of the encrypted private key.

The input and output of the generation system will be made available to the automated verification system.

The verification system:

The automated verificaiton system will match the two private printouts, decrypt them using the master key which is an input to both systems, then verify that the decryupted private key and the public key provided by the generation system are indeed a match.

Upon successful verification:

The public key is made available to the end user.

Private printout #1 is stored in a secure box labeled "secure box #1."
Private printout #2 is stored in a secure box labeled "secure box #2."

In a typical system, these private keys would be printed on small pieces of paper, similar to the small pieces of paper used by some "pull lever" voting booths used in the United States in the second half of the 20th century.

There would typically be thousands or tens of thousands of such pieces of paper in each secure box before the boxes had to be changed.
As boxes are filled, information is recorded to make it easy to identify which box contains which private keys, based on their labels.
The records concerning the contents of each secure box are not considered secure in the scope of this system, but it may be beneficial to keep control access to these records and store them securely.

The idea is that it would be very rare that any of the secure boxes would ever be opened. If they did need to be opened, it would be a manual, labor-intensive task to find the desired information. No computers or other non-manual devices would be involved in finding the "needle in a haystack" if a search were required. Only highly trusted people would be allowed to conduct these searches.

Search procedure:

If an authorized party presented the key-escrow service with the public key, then:

The key escrow service would verify that the request is legitimate and take other steps required by law, such as notifying all parties that have a right to know that the key has been requested in case they have a right to protest.

They key escrow service would look up the label associated with the public key. The label is described under "The generation system" and "The verification system" above.

Using the label, the key escrow service would identify the secure boxes that hold each part of the key.

Seperately, the boxes would be reviewed by trusted employees under secure conditions. No cameras or other recording devices other than "pen and paper" would be allowed in the controlled environment.

The employees would look for the slip of paper in each box that had the correct label.

The employees would write down a copy of the partial encrypted private key and store it in a sealed envelope or other secure container.

They would restore the contents of the box, re-seal it, and return it to secure storage.

The sealed envelopes from each secure box would be taken to a secure area along with the key used to encrypt them. A non-networked computer in a secure area would take the contents of the envelopes and the key used to encrypt them and produce a candidate private key. It would then match it with the public key. If they matched, it would print out the private key. In practice, this computer would be the same as the verification system described above, except that it would print out the decrypted private key.

The private key would be sent to the authorized entity that requested it using a secure method.

Error conditions:

If an error happens during key generation, printing, verification, depositing the partial encrypted keys into the secure boxes, or making the public key available to the user, that public key is never used. If printouts of the partial encrypted keys wind up in the secure boxes, this is not an error. If necessary, a trusted human is called in to replace the secure boxes, clear any mechanical faults, and reset the system.

If an error happens during the printing of the labels for the secure boxes and this error cannot be recovered either automatically or with manual intervention without compromising the contents of the secure boxes, all public keys associated with those secure boxes will be considered invalid and not used.

If the private key used to encrypt the secure boxes is compromised, all public keys produced after the point of compromise will be considered invalid and not used. Optionally, all public keys whose private keys were enrypted with that key will be considered invalid and not used.

If the contents of a secure box are ever compromised, the public keys associated with that secure box should be considered compromised. If possible, they should not be used. Recalls or destruction of devices or accounts depending on these keys may be warranted.

Discussion of variations:

Encrypted keys are split into more than two parts:
By splitting the keys into more than two parts, it makes an actual compromise more difficult. It also makes key retrieval more difficult. However, it makes it easier to have a malicious party compromise one box for the purpose of invalidating all keys associated with that box, since he will have more targets (boxes) to choose from.

The master key changes periodically, e.g. every 1000 keys or every week.
By controlling how often the master key changes, it reduces the impact of a compromised master key. On the other hand, it means there are more master keys to protect.

Multiple copies of printouts can be made to provide redundancy. If this is done, any verification system needs to make sure the multiple copies are in fact the same.
More copies means more redundancy, but it also means more possibilities for either a true compromise or a "forced discard attack" where the goal of the attacker is not to compromise a key but to force the key-escrow service to discard many keys, thereby increasing their cost of doing business.

Vulnerabilities:

This system is inherently vulnerable to false requests which are clever enough to be indistinguishable from a legitimate request.

Human vulnerabilities, such as a compromised or corrupt employee, are always possible. Mitigating these is beyond the scope of this document.

Physical vulnerabilities, such as the secure boxes not being secure from theft or destruction, can be mitigated by creating and maintaining multiple copies of the information held in the secure boxes.

Summary:

By using paper printouts of an encrypted private key, never storing the private key in any electronic system for more than a few seconds, and never storing it in any encrypted system, we can provide a key-escrow system in which the escrowed keys are immune from automated attacks.

This system also considers slow, labor-intensive, high-cost information retreival a desirable feature. By imposing a high high delay and a high monetary cost - which will presumably be paid for by the requesting party - it strongly discourages requests for key retreival.

Patentability:
This was written as an off-the-cuff description of how to secure the private keys after reading 'A few thoughts on Ray Ozzie's "Clear" Proposal' by Nathan Green dated April 26, 2018 ( at http://blog.cryptographyengineering.com/2018/04/26/a-few-thoughts-on-ray-ozzies-clear-proposal/ and http://web.archive.org/web/20180427000040/http://blog.cryptographyengineering.com/2018/04/26/a-few-thoughts-on-ray-ozzies-clear-proposal/ ).
I have some knowledge in technical issues but I am not a security expert.
If I can think of this in a matter of hours, that's proof that there is nothing above that isn't, pardon the pun, "patently obvious."
It is likely that anything closely related to this is also patently obvious.

Errors:
I have not proofread the above. It probably contains ommissions, inconsistencies, and other technical errors. I'm posting it to demonstrate that any ideas along these lines are obvious.

How to play a game is knowledge.
How to win a game is intelligence.
What game to play is wisdom.

Or as a one-liner:

Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.

An application from half a century ago:

Knowledge is knowing the rules of golf and knowing the wind speed and all other relevant playing conditions.
Intelligence is turning that knowledge into the lowest possible score.
Wisdom is not embarrassing your boss or your client on the links.

Or as a one liner:

Knowing how to play golf takes knowledge, playing your best takes intelligence, losing to your boss on purpose takes wisdom.

--
Posted to Slashdot 2018-02-17.

I think the wording above is original, but as they say, "there is nothing new under the sun."

I'm sure I've heard or read something along these lines before.

[original date Wed Feb 11, '15 10:52 AM ]

SSDs already use wear-leveling technology that effectively turn all file-updates into copy-on-write operations.

If SSD devices would keep track of the old copies so that an operating system or SSD-vendor-supplied data-rescue-utility could easily treat non-overwritten data as if it were a "shadow copy"
AND
if the SSD would hide that data from the host computer unless a particular switch or jumper was set,
THEN
it would aide in data recovery after a ransomware attack.

Why hide it from the host when the switch is not set? If the "shadow copy" IS visible to the OS, all the ransomware has to do is write to the disk until the data it wants to erase is no longer there in the "shadow copy." If it is invisible to the host, the ransomware has to write enough data to overwrite all existing "shadow copies" to guarantee success.

Why would a user have the switch on all the time? Backups.
Having a hardware-based "shadow copy" mechanism that the backup software or host OS understood would make backups easier without the necessity of the host OS or filesystem having to implement a shadow-copy system of its own.

--------------------------
[Followup added 5/18/2017 8:08PM UTC, see also http://slashdot.org/comments.pl?sid=10630029&cid=54443823 "You need hard-to-erase disks" which is a reply to http://linux.slashdot.org/story/17/05/18/1757205/wannacry-makes-an-easy-case-for-linux ]

Drive firmware that implemented data-preservation for 72 hours:

All logical blocks are marked as either "in use," "available to be written," or "pending until X" where "x" is a time, in seconds, that the device has received power since it was first initialized.

When a device received a request to write to a logical block, it would see if there was an available logical block. If there was, new data would be written to the new logical block and the old logical block would be marked as "pending until [72 hours from now]."

If there was no available logical block, the write would fail.

An "available logical block" is defined as one that has either never been written to or as one who is "pending until" some time in the past.

A more robust implementation would have "spare logical blocks" that could be used:

If there is no available logical block but there is an available spare logical block, the roles would be swapped:
The block containing the old block would be marked "pending until [72 hours from now]" AND it would be marked as a spare block.
A spare block would be marked as "active" (i.e. not a spare block) and the new data would be written to it.

If "spare logical blocks" are used, then all logical blocks - both spare and active - would have a unique "drive-logical block number."

Under normal circumstances, spare logical blocks and the drive-logical block number and related meta-data would not be visible to the host computer, but they might be made available in a rescue situation by shorting a jumper or issueing special commands to the firmware.

An even more robust implementation would keep a journal of when each block was written to, when each block changed state between live and active and when each one had its "pending until" value changed. This could be used for restoration of recently deleted data.

Considerations:

Host system:

Operating systems would need to be aware that drives may report "success" when deleting data but that the deletion would not result in an increase of free space. Likewise, they would need to be aware that the reported free space may increase at any time for reasons that are opaque to the host system.

Data storage technology:

In situations such as solid-state drives where data must be deleted in very large chunks, the firmware would treat all logical blocks which were in use or which had an unexpired "pending until" time as if they contained data, and treat other logical blocks as if they did not. Physical blocks which did not correspond to an active logical block would be treated as if they did not contain data.

Updated 2018-02-17

Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.

--
Updated 2016-07-08 (the day after a multi-criminal police shooting in Dallas, Texas, USA, leaving 5 police dead, 7 other police injured, and 2 non-police civilians injured)

#IAmDallas - remembering the fallen of 7/7/2016

Updated 2016-04-25 (temporary/for a few weeks)

Ed D., rest in peace my friend, 1968-2016, you were a true fan's fan.

Updated 2014-08-14
All your e are belong to Mother Nature.

Past sigs:

http://slashdot.org/journal/281635/signature-line-update-2012-04-23

http://slashdot.org/journal/94557/my-sig-lines

Storing a private key "in the cloud":

Key is K1. Key is thousands of seemingly-random bits, probably based on a pair of 1024-bit-or-larger prime numbers. You typically store K1 on your computer using a good encryption algorithm. Your password to decrypt the key is P1. P1 is typically tens of characters. Decrypting K1 with P1 is a fast (in human-time-scale) operation, under a second.

Although K1 is typically used to encrypt or decrypt data, for the purposes of this document, K1 is the thing to be encrypted. It will not be used to encrypt or decrypt anything.

Problem:

How to safely store a backup of key K1 online such that the end user can access it from any device if he has both the password P1 and something else that is not mathematically related to K1.

Method 1, the "something else" is a one-time pad:

Create a random one-time pad, R1, which is the same size as K1.
"Encrypt" (XOR) K1 with R1 then encrypt both with P1, creating the safe copy S1. Store S1 online.
Print off a copy of R1 such that it can be easily photographed and re-constructed. Store R1 or an encrypted version of it in a safe place, such as a safe-deposit box or distributed in parts to trusted secret-keepers.
Without R1 it is provably impossible to extract K1 from S1, so S1 is "safe."
R1 by itself is useless.
R1 with S1 constitutes a compromise but it will mean the attacker has to either guess P1 or exhaustively search for it.

If the person loses their local copy of K1, they can use R1, P1, and S1 to reconstruct K1.

Method 2, create a file S2 which from which is computationally hard to extract K1 without P1, acceptably moderately difficult to extract K1 with P1 and no other information, and easy to extract K1 with P1 and "something else" not related to K1.

For example, create a one-time pad R2 which consists of P1 combined with some random-ish filler-number B2 whose size is dependent on how "moderately difficult" it can be to extract K1 given only P1.

If this pad R2 is at least as long as K1, proceed on as in Method 1: "Encrypting" (XOR) K1 with R2 and encrypting both with P1, creating a safe copy S2. As neither P1 nor B2 are known or predicatble, S2 is safe.
The time to recover K from S2 with only P1 will be the time it takes to go through all (or, on average, half) of the possible values of B2. Since the length of B2 was chosen in advance based on how hard this decription should be, K1 will be recoverable in a predicable, acceptable amount of time. With B2 and P1 recovering K1 from S2 is quick.

If the pad R2 is not as long as K1, one option is to re-use the one-time pad and as such will not satisfy the goal o being "comptationally hard to extract K1 without P1," but it may be good enough for some applications.

A different solution is to encrypt K1 with P1 (the file that is normally stored on the person's local computer will qualify) then encrypt the result with either B2 or some combination of P1 and B2 to create S2. The difficulty of extracting K1 from S2 with only P1 depends on the time it takes to go through all (or, on average, half) of the possible values of B2. Depending on the lenghts of P1 and B2 and the encryption algorithms used, this may not be safe enough. With B2 and P1, recovery is quick.

This method has the advantage that the "something else," B2 in this case, need not be kept at all.

A typical scenario where the "B2" method would be preferred over the "R1" method is where it is acceptable if key K1 becomes unavailable for an extended period of time in exchange for a zero-risk that an adversary will acquire or discover R1.

A self-proving identification card:

Display in human-readable and computer-readable form:
Identifying information such as name, card number, issuer/certifying agent, expiration date, face or thumbprint, signature, etc.

Display the same in a computer-readable form. For easy-to-scan things like letters and numbers that are on the card in a pre-defined layout, the human-readable form and computer-readable form may be identical.

For things like a photo, the computer-readable form may be a simpler version, such as an 8- or 16-color 64x64 bitmap.

Have the comptuter-readable form be digitally signed by the issuer/certifying agent and have the signature on the card in both a computer- and human-readable form.

Have the scanning device display the computer-read data in a human-readable form so that a human being can compare what is on the screen with what is on the card.

The same human being would compare what is on the card with either another form of ID or, if the card had a picture or thumbprint, with that of the person presenting the card.

OPTIONAL:
Some information on the card could be encrypted and require a password or other authentication token to decrypt.

Other than this optional part, the card would be "self proving" provided that the public key of the issuer/certifying agent was available to the authentication terminal.

The surviving Boston Bombing suspect has not read his rights and as of Monday April 22, 2013, it's been several days since his arrest. Law enforcement has already said they believe the two bombers were acting alone. It would be one thing to press a suspect for information if you catch a guy and think an accomplice is about to set off another one within hours but anything after that is trampling on the Constitution. Therefore we petition the White House to only use the "imminent threat" exception to the Miranda warning when the threat really is imminent and getting information now is more important than preserving the Constitution.

White House Petition URL:

http://petitions.whitehouse.gov/petition/quickly-mirandize-arrested-people-no-matter-how-serious-crime/DncN0Pm2

Handling older juveniles accused of serious crimes

Most states try to certify older juveniles arrested for serious crimes as adults. "You do an adult crime, you do adult time," as the saying goes.

The human brain's moral centers don't reach full adult maturity until the early or mid-20s. This is reflected in our law and legal history.

Until the Vietnam era, some states would not let you vote until you turned 21. The logic was that young adults were too immature or ill-informed to vote responsibly.

While we now give anyone old enough to serve in the military without his parent's consent the right to vote, we have taken away the right to buy or consume alcohol without parental supervision. We did this because we saw that way too many people under 21 were using alcohol irresponsibly and killing or maiming themselves and others as a result. Prior to the laws being changed, people over 21 drank irresponsibly and killed people at a significantly lower rate than those under 21.

Knowing this, we need to change our court system so those convicted of crimes done before age 18 are at least offered a path to rehabilitation and, once their complete sentence, parole, and a possible short period after parole is complete without any new crimes committed as an adult, the assurance that their records will be sealed.

At least one state has implimented the option of a "determinate sentence" for youth over a certain age but young enough to be tried as a juvenile. Here is how it works:

* The prosecutor decides not to ask for an adult trial OR a judge turns him down
* The youth pleads guilty or is convicted and given either a "determinate sentence" of a stated number of years or decades, an "indeterminate" (traditional) youth sentence which means he gets out by a certain age or sooner, or a non-prison sentence such as home confinement or youth probation.

Assuming he gets a "determinate sentence" and is not yet old enough to be transfered to an adult prison:
* The youth goes to a youth correctional facility with a focus on rehabilitation
* If the youth serves enough time to be paroled before becoming a young adult, he MAY be paroled
* Under some situations, the youth may be paroled or discharged when he becomes a young adult
* If the youth is not paroled or discharged at this time, he is transferred to adult prison
* The now-adult inmate will eventually become eligible for parole if he his not already
* The inmate or parolee eventually serves his stated sentence and parole and is discharged
* The juvenile record is sealed

That last item is key. It's the "you can start your life over now, the mistakes of your immature-brained youth are forgiven" element that any society with a moral compass will have as part of its juvenile justice law.