Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Re:What's the big problem? (Score 3, Informative) 489

From a fellow Canuckistanian:

Remember that we, in Canada, have a fairly unified banking system. Really, we've got the big 5, and we've got the Interac system, and any bank that wants to sign on, signs on.

In the US, however, you've got thousands and thousands of banks. They don't have a unified banking system; they have the big Credit Card companies.

But, yes, we've been on swipe and pin for decades, and chip and pin for years, and applepay Just Worked when the banks turned it on, because virtually any place that's set up for electronic transactions already has a tap capable terminal, and the infrastructure's all already there.

Comment Re:For those who may have forgotten (Score 1) 57

That certain was an important decision, but the Bell System was still requiring customers to have expensive coupler equipment installed for many years afterwards (that article was from 1974). Those couplers involved transformers that would have made even 56k modems impractical, much less DSL.

For sure, where I lived, the Bell breakup was the dividing line, after which we were allowed to buy phones from someone other than the phone company. I still remember when we got our first non-Bell telephone, though I was a young kid at the time, and it was after Bell broke up. More amusingly, we weren't even in Bell territory; we were served by GTE. That's how wide-ranging the implications of the breakup were. It rocked the industry, and changed things pretty dramatically for the better.

Comment Re:Yes, deleted files are (sometimes) recoverable (Score 1) 60

For spinning rust that works just fine, most of the time. Flash is another story entirely. It's likely that your overwrites will get put into _other_ free cells, and the flash controller will mark the cells you're trying to overwrite as free, rather than overwriting them. Depending on your usage patterns, they might _never_ get overwritten. Aaaaaaand we're back to the problem we were trying to solve... just one layer lower. :(

There actually is a way, but it involves creating a file that's as big as the remaining space on the volume, to ensure that there are no flash pages that don't get rewritten. And even then, that doesn't quite guarantee that it will get overwritten because the flash page you're trying to overwrite could get spared and replaced with a free page. Obviously if you do that enough times, it will eventually get overwritten, but you'll also drastically shorten the life of the flash disk.

A better solution, of course, is to have a flash controller that supports TRIM properly and guarantees that overwritten pages get zeroed in a timely manner. If you have that, then overwriting the data once is sufficient, because the data will eventually get zeroed. And frankly, there's no good reason for a flash controller to not aggressively erase pages that are no longer tied to the filesystem (the old version of the data), because they are unlikely to ever be used again.

Comment Re:Not a SQLite problem (Score 1) 60

In SQLite, you can do "PRAGMA secure_delete=ON;" and it will subsequently overwrite all deleted information with zeros. This is turned off by default because it does more disk I/O. Alternatively, one can run "VACUUM" at any time to ensure that all deleted content has been purged from the database file.

The concern goes deeper than just disk I/O. On flash, there's a limited number of writes per flash erasure block, and using it in a mode that continuously overwrites everything you delete significantly increases the rate at which you burn through those write cycles. The OS is likely to coalesce a lot of those writes if they happen close enough together, but you're still abusing the hardware pretty badly by doing that.

The right approach is to come up with a reasonable policy for retention, e.g. "Guaranteed to not retain data more than n hours" and then vacuum the database every n hours, or when the OS tells you that your app is about to get terminated (assuming you can safely do it in such a short time), or when your app gets backgrounded (if you can't). Either way, vacuuming constantly is bad for the hardware, and never vacuuming is bad for security. The key is to find the right balance, and that pretty much requires your programmers to know that this issue exists, which most SQLite users no doubt do not.

And a couple of aspects of the design of iOS contribute to this problem negatively. If this were on a real computer:

  • You'd probably have a MySQL or PostgreSQL instance holding that data, and it would scrub periodically in the background. You can't do that you iOS, because you can't have a background daemon running when your app isn't running, so everybody ends up using SQLite, which is just barely enough of a database to be usable.
  • You wouldn't have the OS killing your app randomly while it is backgrounded, making it impractical to guarantee that you'll get n seconds to scrub every so many hours.

I'd love to see iOS add a centralized SQL database running on it at all times, with periodic scrubbing, with the ability to selectively share tables across apps, etc.

Comment For example (Score 1) 15

Blocklist: Trump, Hilary, Clinton, DNC, RNC, Democrat, Republican, Libertarian, Green, gun control, s**t, f**k, h**l, ...

Actual posts filtered:

  • Google Trumps Apple as #1 on NASDAQ
  • California Drought Finally Over? Green Grass Says "Maybe"
  • Shitake Mushrooms Pulled Over E. Coli Concerns
  • Hello. My Name is...

Word bans don't work. They never did. To do this right would involve significant amounts of machine learning, and you wouldn't need a list of things to ban if they were doing that.

Comment Re:So make it equally first amendment to block the (Score 3, Informative) 175

The state law closed the loophole the politicians left in the federal do-not-call system. Yay for the state.

The state could have accomplished the same end by banning all robocalls that the recipient didn't specifically sign up for. Since that wouldn't be based on the content of the calls it wouldn't be subject to this particular 1st Amendment challenge. By banning politicial robocalls in particular they guaranteed that the law would be found to violate the 1st Amendment.

Comment It wouldn't make sense anyway (Score 1) 108

I don't want my TV producers negotiating with my hardware manufacturers or software developers. I want them negotiating with me, the person who watches the TV. Why the fuck should such a totally-unrelated third party be involved? How can that possibly be in my best interests?

It's not just a little weird; it's totally absurd. It's like if a I drive to the store to buy some socks, and what socks are available depends on a deal between the textile producer and my car manufacturer. WUT?! Believe me: this is not a way to get me to buy your socks or your car. This is something a sockmaker or carmaker thinks up when they're out of ideas and know that there are vastly better and cheaper socks and cars available.

Comment Re:Imagine (Score 1) 108

How free is this free market? Are content producers allowed to negotiate amoung themselves to fix prices? Are they allowed to pick and choose where to offer services? Are they allowed to enforce odious restrictions? Are they allowed to solicit 'incentives' from geographic regions to set up shop?

Slashdot Top Deals

Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy.

Working...