If you think HTML can become binary data always fetched a database, you've never done any Web coding in your life. As for Swift, keep that on your iToys.
It's binary either way, dumbass. When you buy a BluRay, do you get excited for the "DIGITAL COPY" they'll loan you despite the fact that the disc itself already contains a (vastly superior) digital copy?
It is being expanded and turned into its own division.
No, it's being pinched off like a dingleberry. If it ever bears fruit because someone else takes an interest and does something with it, they'll parade it about and sing its praises as if they've always believed in it. All of the suckers who bought one (at ridiculous prices) have nothing to show for it and have been cut off from any and all further development / revisions. The only ones with access to it going forward will be Google and whatever company decides they want to pay Google $BIG_MONEY$ to get their hands on it.
Ignore how it looks. Put it behind the TV. Get a good looking case. Get one of them thar mini PCs. Get one of them thar mini PCs AND put it behind the TV. Not exactly a difficult "problem" to solve.
http://www.tronsmart.com/ That is the 'dongle' to get. Based on kikat 4.4 and has everything from usb3 to any video you throw at it playback. Not to mention it's quad-core arm cpu.
I guarantee you it won't play higher quality h.264 bluray rips, let alone h.265 rips.
It's called a PC. Hook it up to the TV (or receiver if applicable) and the network. Play anything video you want. Play any audio you want. Access the full internet. Play games. Do all the fucking things. Laugh at DRM. Torrent to your heart's content.
Funny, I can access all of those things without any sort of hardware DRM, which is what the topic of discussion is.
You can't access the full quality Netflix stream on any open platform. Consoles, Rokus, "Smart" TVs, etc. get full quality streams. PCs don't. (You can't even fucking get surround sound.)
They are making things right tomorrow by upgrading every Dexluxe owner for free and putting back the features in next year's version. The CEO also gave a very sincere apology.
>"Firefox Succeeded In Its Goal -- But What's Next?"
Here is what I *HOPE* is next:
1) Stop trying to be and look like Chrome. Just stop.
2) Stop trying to force users to not have tabs on bottom, having a menu bar, having separate buttons, etc. Let users control their user interface how they want.
3) Remove all that developer stuff that 99.99% of users don't use or care about and put it in an addon.
4) Remove all that chat and conferencing stuff that 99% of users don't care about and put that also in an addon.
5) Focus on speed, security, stability, bug-fixing, and documentation. You don't have to be a feature-of-the-month club.
6) Continue to support as many platforms and systems as possible, including old ones.
Oh- and thank you for all the hard work that went into Firefox- the browser of my choice (and that for my users, family, and friends) for the last decade.
You forgot the most important part - bring back the fucking status bar you fucking shits.
Acronyms are great, "backronyms" are stupid, "hackronyms" and "recursonyms" are fucking retarded. SAFFiR for "Shipboard Autonomous Firefighting Robot" takes the fucking cake though. Why not SAFER for "Shipboard Autonomous Fire Extinguishing Robot"? Or how about just Firefighting Robot?
This is a fair counterargument I guess. But I would posit that the number of people willing to pick up a hitchhiker is massive compared to the number of people with bad intentions.
I posit that you're an idiot. And I have more evidence (your posts) for my argument than you do for yours. Hitchhiking was "safe" in the 1960s when everyone was doing it and people were willing to give rides (for gas, grass, or ass - nobody rides for free). Today both hitchhikers and the people who pick them up are far fewer - good intentioned people fear a hitchhiker may attack them and won't give people rides. Good intentioned people who need rides fear the person who picks them up may attack them. What you're left with on both sides is a reduced pool with a higher concentration of crazy.
You aren't. The clown is wrong. Saying something is "comprised of" something is perfectly acceptable. It's a transitive verb. See "make", "made of", "making", etc., or pretty much any other transitive verb.
You're wrong, as is the idiot trolling Wikipedia with his edit crusade and baseless essay. (I fully support any and all trolling of Wikipedia.) Comprise is a transitive verb, like the word make. It originates from the Latin comprehendere. If you want to take up this clown's crusade you'll have to take up the same crusade against nearly every transitive verb there is.
Shit makes your posts. Shit makes up your posts. (The "up" isn't necessary, but is common as it can disambiguate "Shit".) Your posts are made of shit. Your posts, being made of shit, are shitty.
Shit comprises your posts. Your posts are comprised of shit. Your posts, comprising shit, are shitty.
If you still don't get it, think about why a transitive verb is called a transitive verb.
The post I quoted is the one everyone is attacking you for, and is the one everyone, including oodaloop, is referring to. You don't get to pretend you didn't type it, or that people were referring to something else. Please DON'T try again, it's pathetic.
There are a number of solutions to the problem. There are data protection appliances that can be integrated to databases or applications (via API) where encrypted data is sent to for decryption and available only in the result set; never written to disk in the clear. In this scenario, even root or dba don't have access to the sensitive data, unless authorized by the appliance. Another option, (becoming more popular) is tokenization. The sensitive data is replaced by consistent non-sensitive token values. This often allows for many business analytic processes to operate on non-sensitive data. In many scenarios, all of the work in the main application/database can be done with tokens and then a secure 'detokenize' app is provided to specific users that may need the real data. Tokens can also retain some of the original data. So if we tokenized SSN 123-45-6789, we could generate a token that kept the same last 4 digits, 541-30-6789. If customer support uses the last four digits of SSN to verify customers on the phone, they can now do it without being exposed to the real sensitive data.
(Disclaimer: I work for a data protection company that does this kind of stuff)
Exposing plaintext data, even a portion of it, defeats the entire point of encryption. The last 4 digits of an SSN are a terrible thing to expose. A typical practice is leaving the first 4 digits of a credit card account number in plain text so you can search against them. The last 4 are easy to get (rummage through mail, or call up customer service and say you didn't get the bill, they'll say it was paid, you'll ask "what card was it on", they'll say "I can only tell you the last 4 digits and the fact that it was a Visa, etc.). Armed with the first 4, last 4, and the fact that it's a Visa, you significantly narrow down the possibilities due to the algorithms used in generating account numbers. Another practice is exposing the first few letters of the last and first name. This lets you search and sort better, but it makes your shit that much more vulnerable.
But if you're going to do it, tokenizing it in that manner is ridiculous - you should be using an encrypted column for the real deal and a plaintext column for the exposed shit. None of this whackery where a single column has the same length and characteristics of the real deal, AND you've got the real deal encrypted elsewhere. If 123-45-6789 is real it should be encrypted (fully) in some other column. The column with 541-30-6789 should simply be a column with 6789. If your 541-30- is based on 123-45- at all, then you're obfuscating only 5 fucking digits. Given someone's date of birth you can guess the first 1 or 2 digits. You can to 2 or 3 based on address as well in many cases. If your 541-30- is random, then it serves zero purpose and there's no need for it. Storing, fetching, and indexing the column without that extra shit will give you performance increases. You can store 9999 as a 2-byte int, where as you need 11 bytes of char data for 541-30-6789, or 4 bytes of integer data if stored as 541306789. Further, the index will be much more effective when it's only indexing the shit that matters.
It's not a matter of "why not just" anything. Keys in memory just mean an attacker runs a memory dump once the system is online. Keys in a file means an attacker reads that file. All major database servers will use an encryption keystore to encrypt the keys with the credentials of the service account the database runs under. They're not plaintext files, they're protected as strongly as the service account itself. If this is set up properly, it means an attacker that can get at the key on disk you can also run a memory dump to get the key in memory. The only additional things "key-in every boot" protects against are someone absconding with your physical disks / servers or you using a trivial password for the account. (Potential vulnerabilities that let you get into the account's keystore are traded for potential vulnerabilities that let you dump memory you shouldn't have access to.)
You can't encrypt your data and decrypt it without the key and data existing in the same place at some point. Even if you have a hardware module the handles the encryption and decryption, it's going to be sending out unencrypted data (or data encrypted only by something like HTTPS) - this means any legitimate device downstream gets the unencrypted data. Compromise any legitimate device downstream (web server, report server, lackey's laptop, etc.) and you win. Encryption only protects data at rest and data in transit. Data in use is always as vulnerable as the device using it.
Further, at-rest encryption means you can't search for shit.
[Last Name] [First Name] [SSN] [Date of Birth] SELECT * FROM Suckers WHERE [Last Name] = 'Smith'
If [Last Name] is encrypted, your search will involve the decryption of all data for that column, or all distinct data for that column if you indexed it and store the index in a separate file (or used some transparent database-wide feature to do so). With millions to billions of rows, complex queries, and wide tables, this becomes impractical. There are hacks that let you "sort of" search by doing stupid shit like using a hash of the last name or having a separate column in plaintext, such as for the last initial, but these all expose some portion of data in order to somewhat increase performance.
I wasn't vilifying anyone. Nowhere in that statement did I refer to the GOP, or indeed any particular organization, person, or group. I was making a statement that bad behavior is bad behavior, even when everyone does it. Gerrymandering is hurting our country, and that's gerrymandering both by the GOP AND the DNC.
Now I'm going to vilify someone: Your bias and knee-jerk politics are showing. You're seeing persecution where none exists. I bet you're a fundie, too.
Well, that's democracy in its current form for you. In 2010 the GOP got to re-draw congressional districts, and they gerrymandered them in such a way that anyone other than a staunch right-wing Republican will never ever get elected. You could run Jesus against the GOP candidate and it would be close.
Moderation is abused every single time. On Slashdot, it's abused by actual users, sockpuppet "users", and the admins. Browse at -1 if you want to see the best posts.
If you break compatibility it's a new product and needs a new name. If you want that name to be "Product 2.0" that's fine, as long as you keep supporting the original version.
Slashdot Mirror
So are count-downs. 3, 2, 1, 0, -1...
So are count-tos.
1, 2, 2 and a half, 2 and three quarters...
Disband the FBI and hang the treasonous fucks in the town square as enemies of the state.
If you think HTML can become binary data always fetched a database, you've never done any Web coding in your life. As for Swift, keep that on your iToys.
It's binary either way, dumbass. When you buy a BluRay, do you get excited for the "DIGITAL COPY" they'll loan you despite the fact that the disc itself already contains a (vastly superior) digital copy?
It is being expanded and turned into its own division.
No, it's being pinched off like a dingleberry. If it ever bears fruit because someone else takes an interest and does something with it, they'll parade it about and sing its praises as if they've always believed in it.
All of the suckers who bought one (at ridiculous prices) have nothing to show for it and have been cut off from any and all further development / revisions.
The only ones with access to it going forward will be Google and whatever company decides they want to pay Google $BIG_MONEY$ to get their hands on it.
Ignore how it looks.
Put it behind the TV.
Get a good looking case.
Get one of them thar mini PCs.
Get one of them thar mini PCs AND put it behind the TV.
Not exactly a difficult "problem" to solve.
http://www.tronsmart.com/
That is the 'dongle' to get. Based on kikat 4.4 and has everything from usb3 to any video you throw at it playback. Not to mention it's quad-core arm cpu.
I guarantee you it won't play higher quality h.264 bluray rips, let alone h.265 rips.
It's called a PC. Hook it up to the TV (or receiver if applicable) and the network. Play anything video you want. Play any audio you want. Access the full internet. Play games. Do all the fucking things. Laugh at DRM. Torrent to your heart's content.
There is no substitute.
Funny, I can access all of those things without any sort of hardware DRM, which is what the topic of discussion is.
You can't access the full quality Netflix stream on any open platform.
Consoles, Rokus, "Smart" TVs, etc. get full quality streams. PCs don't. (You can't even fucking get surround sound.)
So I don't use Netflix.
I wish someone would steal my identity and do my taxes.
(I owe money every year because I don't like giving the government interest-free loans.)
They are making things right tomorrow by upgrading every Dexluxe owner for free and putting back the features in next year's version. The CEO also gave a very sincere apology.
https://www.linkedin.com/pulse...
They'll just try it again later.
>"Firefox Succeeded In Its Goal -- But What's Next?"
Here is what I *HOPE* is next:
1) Stop trying to be and look like Chrome. Just stop.
2) Stop trying to force users to not have tabs on bottom, having a menu bar, having separate buttons, etc. Let users control their user interface how they want.
3) Remove all that developer stuff that 99.99% of users don't use or care about and put it in an addon.
4) Remove all that chat and conferencing stuff that 99% of users don't care about and put that also in an addon.
5) Focus on speed, security, stability, bug-fixing, and documentation. You don't have to be a feature-of-the-month club.
6) Continue to support as many platforms and systems as possible, including old ones.
Oh- and thank you for all the hard work that went into Firefox- the browser of my choice (and that for my users, family, and friends) for the last decade.
You forgot the most important part - bring back the fucking status bar you fucking shits.
Or Mulberry.
Or Gmail.
Acronyms are great, "backronyms" are stupid, "hackronyms" and "recursonyms" are fucking retarded.
SAFFiR for "Shipboard Autonomous Firefighting Robot" takes the fucking cake though. Why not SAFER for "Shipboard Autonomous Fire Extinguishing Robot"?
Or how about just Firefighting Robot?
This is a fair counterargument I guess. But I would posit that the number of people willing to pick up a hitchhiker is massive compared to the number of people with bad intentions.
I posit that you're an idiot. And I have more evidence (your posts) for my argument than you do for yours.
Hitchhiking was "safe" in the 1960s when everyone was doing it and people were willing to give rides (for gas, grass, or ass - nobody rides for free).
Today both hitchhikers and the people who pick them up are far fewer - good intentioned people fear a hitchhiker may attack them and won't give people rides. Good intentioned people who need rides fear the person who picks them up may attack them. What you're left with on both sides is a reduced pool with a higher concentration of crazy.
You aren't. The clown is wrong. Saying something is "comprised of" something is perfectly acceptable. It's a transitive verb. See "make", "made of", "making", etc., or pretty much any other transitive verb.
You're wrong, as is the idiot trolling Wikipedia with his edit crusade and baseless essay. (I fully support any and all trolling of Wikipedia.)
Comprise is a transitive verb, like the word make. It originates from the Latin comprehendere. If you want to take up this clown's crusade you'll have to take up the same crusade against nearly every transitive verb there is.
Shit makes your posts.
Shit makes up your posts. (The "up" isn't necessary, but is common as it can disambiguate "Shit".)
Your posts are made of shit.
Your posts, being made of shit, are shitty.
Shit comprises your posts.
Your posts are comprised of shit.
Your posts, comprising shit, are shitty.
If you still don't get it, think about why a transitive verb is called a transitive verb.
Yet you seem to know exactly what they meant.
Funny how language changes over time. Even Ye Olde English!
The headline had me thinking the craters were popping.
They are not popping.
The post I quoted is the one everyone is attacking you for, and is the one everyone, including oodaloop, is referring to. You don't get to pretend you didn't type it, or that people were referring to something else.
Please DON'T try again, it's pathetic.
Fixed the fix for ya both!
I'm not even going to fix the fix for the fix for your fucks.
There are a number of solutions to the problem. There are data protection appliances that can be integrated to databases or applications (via API) where encrypted data is sent to for decryption and available only in the result set; never written to disk in the clear. In this scenario, even root or dba don't have access to the sensitive data, unless authorized by the appliance. Another option, (becoming more popular) is tokenization. The sensitive data is replaced by consistent non-sensitive token values. This often allows for many business analytic processes to operate on non-sensitive data. In many scenarios, all of the work in the main application/database can be done with tokens and then a secure 'detokenize' app is provided to specific users that may need the real data. Tokens can also retain some of the original data. So if we tokenized SSN 123-45-6789, we could generate a token that kept the same last 4 digits, 541-30-6789. If customer support uses the last four digits of SSN to verify customers on the phone, they can now do it without being exposed to the real sensitive data.
(Disclaimer: I work for a data protection company that does this kind of stuff)
Exposing plaintext data, even a portion of it, defeats the entire point of encryption.
The last 4 digits of an SSN are a terrible thing to expose.
A typical practice is leaving the first 4 digits of a credit card account number in plain text so you can search against them.
The last 4 are easy to get (rummage through mail, or call up customer service and say you didn't get the bill, they'll say it was paid, you'll ask "what card was it on", they'll say "I can only tell you the last 4 digits and the fact that it was a Visa, etc.).
Armed with the first 4, last 4, and the fact that it's a Visa, you significantly narrow down the possibilities due to the algorithms used in generating account numbers.
Another practice is exposing the first few letters of the last and first name. This lets you search and sort better, but it makes your shit that much more vulnerable.
But if you're going to do it, tokenizing it in that manner is ridiculous - you should be using an encrypted column for the real deal and a plaintext column for the exposed shit. None of this whackery where a single column has the same length and characteristics of the real deal, AND you've got the real deal encrypted elsewhere. If 123-45-6789 is real it should be encrypted (fully) in some other column. The column with 541-30-6789 should simply be a column with 6789.
If your 541-30- is based on 123-45- at all, then you're obfuscating only 5 fucking digits. Given someone's date of birth you can guess the first 1 or 2 digits. You can to 2 or 3 based on address as well in many cases.
If your 541-30- is random, then it serves zero purpose and there's no need for it. Storing, fetching, and indexing the column without that extra shit will give you performance increases. You can store 9999 as a 2-byte int, where as you need 11 bytes of char data for 541-30-6789, or 4 bytes of integer data if stored as 541306789. Further, the index will be much more effective when it's only indexing the shit that matters.
It's not a matter of "why not just" anything. Keys in memory just mean an attacker runs a memory dump once the system is online. Keys in a file means an attacker reads that file. All major database servers will use an encryption keystore to encrypt the keys with the credentials of the service account the database runs under. They're not plaintext files, they're protected as strongly as the service account itself. If this is set up properly, it means an attacker that can get at the key on disk you can also run a memory dump to get the key in memory. The only additional things "key-in every boot" protects against are someone absconding with your physical disks / servers or you using a trivial password for the account. (Potential vulnerabilities that let you get into the account's keystore are traded for potential vulnerabilities that let you dump memory you shouldn't have access to.)
You can't encrypt your data and decrypt it without the key and data existing in the same place at some point.
Even if you have a hardware module the handles the encryption and decryption, it's going to be sending out unencrypted data (or data encrypted only by something like HTTPS) - this means any legitimate device downstream gets the unencrypted data. Compromise any legitimate device downstream (web server, report server, lackey's laptop, etc.) and you win.
Encryption only protects data at rest and data in transit. Data in use is always as vulnerable as the device using it.
Further, at-rest encryption means you can't search for shit.
[Last Name] [First Name] [SSN] [Date of Birth]
SELECT * FROM Suckers WHERE [Last Name] = 'Smith'
If [Last Name] is encrypted, your search will involve the decryption of all data for that column, or all distinct data for that column if you indexed it and store the index in a separate file (or used some transparent database-wide feature to do so). With millions to billions of rows, complex queries, and wide tables, this becomes impractical.
There are hacks that let you "sort of" search by doing stupid shit like using a hash of the last name or having a separate column in plaintext, such as for the last initial, but these all expose some portion of data in order to somewhat increase performance.
I wasn't vilifying anyone. Nowhere in that statement did I refer to the GOP, or indeed any particular organization, person, or group. I was making a statement that bad behavior is bad behavior, even when everyone does it. Gerrymandering is hurting our country, and that's gerrymandering both by the GOP AND the DNC.
Now I'm going to vilify someone: Your bias and knee-jerk politics are showing. You're seeing persecution where none exists. I bet you're a fundie, too.
Well, that's democracy in its current form for you. In 2010 the GOP got to re-draw congressional districts, and they gerrymandered them in such a way that anyone other than a staunch right-wing Republican will never ever get elected. You could run Jesus against the GOP candidate and it would be close.
Try again, dipshit.
Moderation is abused every single time. On Slashdot, it's abused by actual users, sockpuppet "users", and the admins.
Browse at -1 if you want to see the best posts.
This is perfect for iPhone users!
If you break compatibility it's a new product and needs a new name.
If you want that name to be "Product 2.0" that's fine, as long as you keep supporting the original version.