> If you have an American Express or Discover card you can enter your online credentials we'll load your charge names directly to check them for fraud. Your credentials are transmitted securely and then cleared after querying. No personal information will be collected. Your card will never be charged.
Never ever ever ever do this. This is a terrible idea and if this is a legit site, they should never offer this as an option
I put in test/test as the creds and it claimed to query and start collecting the data
> Please wait while your report is being generated... > Parsing account information > Querying for transaction information > Parsing transaction information > Loading charge batch
Then I gave up waiting as my tracking blocking went crazy.
> If you have an American Express or Discover card you can enter your online credentials we'll load your charge names directly to check them for fraud. Your credentials are transmitted securely and then cleared after querying. No personal information will be collected. Your card will never be charged.
Never ever ever ever do this. This is a terrible idea and if this is a legit site, they should never offer this as an option
Another question about this, presume #1 10 gb, #2 20 gb, #3 35 gb
We have #1 and #2 open, #3 is taking 50% of the 'free space' shown. Is writing data in #1 or #2 have a roughly 50% chance of destroying data in #3 or does it known mapped blocks and the overwrite only happens once the actual free amount is used up?
Currently, we achieve this with overcommitting the volume size: if you have, say, 1 GB device, and you format it with a 3-volume Shufflecake setup, each of these 3 volumes will appear as 1 GB in size. Then the question is, what happens if you write more than 1 GB in total? Well, you will start receiving I/O errors. Volumes themselves will not get corrupted, because they will not clobber each other, but the kernel module will basically tell you "sorry, I ran out of space earlier than I expected".
A planned feature in the future, to manage this more elegantly, is to use "virtual quotas". With this system, low-secrecy volumes will have a limited size (chosen by the user), but the "topmost" unlocked volume (the "most secret one" that you have unlocked with a given password) will not have this limit: it will always appear as taking all the leftover space. See the section 6.5 "Use of Disk Metadata" in the research paper.
3-volume Shufflecake setup with on a 100 gb device. I put 10 gigabytes into #1, 20 gigabytes in #2 and so in #3, I can only store 70 gb of data before I get I/O errors, which leaks that there's 30 gigabytes of data in the other volumes.
I'm no expert on his current activities, but this isn't a situation without Known Context.