High frequency traders effectively charge money to provide liquidity.
But they provide far more than I need. I'm not worried about liquidity when I eventually sell those stocks, and if I could opt out of buying extra liquidity I definitely would.
If I have a medium size order, then even though they lower the spread they also front-run and limit how much I can buy at that price. So I'd rather have them not be there.
If I have a tiny order, then I don't care what the spread is within reasonable bounds, and I still don't want them to be there.
oh, well, if you're a speculator, often you really do lose money to hfts because they're better speculators than you, but it's unclear why anybody outside your immediate family should care about that
if you're an investor, otoh, the lower spread and greater liquidity means timely execution costs you less, not more. you aren't paying them for liquidity; they're paying you, or rather you're paying them, but much less than the spread you'd've paid an old-style open outcry market maker
(do you even remember markets before decimalization? minimum spread 12.5 cents)
of course you do need to execute intelligently; you can't just plop a million-dollar order in a hundred-million-a-day market and expect the market not to move against you
> of course you do need to execute intelligently; you can't just plop a million-dollar order in a hundred-million-a-day market and expect the market not to move against you
It's fine for the market to move against big orders, I just want the movement to, like, take one second. I don't want anyone to change their position in response to an order that hasn't even resolved.
> (do you even remember markets before decimalization? minimum spread 12.5 cents)
Well I'm not suggesting we undo that.
> if you're an investor, otoh, the lower spread and greater liquidity means timely execution costs you less, not more. you aren't paying them for liquidity; they're paying you, or rather you're paying them, but much less than the spread you'd've paid an old-style open outcry market maker
In this scenario I'm a long-term investor so the cost means nothing to me. So it's a matter of whether I want HFTs to profit, and I don't, because their actions are often not win-win. If HFT worked somewhat differently I wouldn't mind them the same way.
Do you just plan to save your money in dollar bills hidden inside a pillow until you retire? If you want to invest it in any way, you probably want to avoid floating point numbers for keeping track of it.
Uh? Where did you get that comparison? China's top income tax rate is 45%. I cannot see how that could ever be "far below" what someone's income tax rate would be in California (37% federal + 12.3% state). Mind that the top bracket starts around $140k in China, whereas in the US it's about $590k (federal or Californian).
yeah so we need a new category for California since they set thenselves up to seize more of the means of production than the communists/state capital socialists
If I have access to the physical device and the SD card/USB drive in order to pull off an attack that secure boot prevents, then why wouldn't I just take the whole damn device and swap it with my own? Presumably the network/gpio/etc. are the important part here and not the Pi.
Well, if you have physical access, you can always do basically anything. I'm sure you can easily mess up a lot of industrial equipment with your bare hands.
However, let's say that the said industrial equipment is stored in a security box, with tamper-resistant screws, and you are on camera. It's a lot harder to tamper with then, compared to just plugging in a flash drive and rebooting the Pi into USB boot; at least in theory. Ditto for helping to prevent persistent remote attacks.
There are several industry grade devices based on raspberry pi platform, LOL. Not just media servers.
Some people also deploy them outdoors to stuff like weather, ADS-B etc. Some make it into cubesats.
Don't just underestimate its use cases.
I am far from someone who can evaluate the legal questions here. However, two notes:
- Legalweb, which OP references, sells services for GDPR compliance. While that may make them familiar with these rules, I wouldn't view them as an impartial perspective.
- The jsdelivr post quotes actual attorneys. While they are certainly not impartial, I’d feel a bit more confident with their interpretation given that the firm is actually named. I could not find anything on Legalweb on who’s actually behind it, though I did see this quote: ”As a software manufacturer, we are not allowed to offer individual legal advice.”
If someone can find a more independent interpretation, that would probably be ideal.
It doesn't seem like there's any reason to be suspicious about Legalweb. The attorneys in jsDelivr's post can be lifted up without putting Legalweb down.
There isn't much said editorially in the jsDelivr post. They didn't use a blockquote but it appears to be quoted until the last paragraph where it says "In conclusion". There are no editorial assertions in the intro. The conclusion appears not to match up with what the attorneys say.
What the attorney says is that jsDelivr, the service, is safe. It doesn't say that about sites that use it.
I agree with both the article and with jsDelivr's posts except the conclusion. jsDelivr will not be shut down just because of this ruling, but site owners may want to stop using it.
Here's the conclusion:
> In conclusion, the ruling that has been so controversial recently does not seem to fully address the factual and technical circumstances of how jsDelivr works, and at this point as a single ruling should not lead to any real concerns about using CDN's services. The arguments for extending to other online services a single ruling strongly emphasizing Google's failure to adequately protect personal data are insufficient and lack substance.
"should not lead to any real concerns" doesn't inspire confidence
It only seems complex because everyone has been implementing user-hostile datamining operations for years before GDPR was enacted. So for every external service you use, you must make sure that they implemented GDPR compliance or not. If GDPR had been a law since the beginning, it would be much simpler.
Although I'd like to know, what difficulties have you been facing in your startup, exactly?
I have dozens of matters that I don't even know if they are related to GDPR.
Our main DB is physically hosted in a EU data center by a US company (not AWS). Is this GDPR compliant? Because, as I understand it, US companies can be required to share their data with the US govt. Does that mean I should be looking to host my DB with a non US company? Does signing a DPA and putting some clause in our privacy terms be enough to be compliant?
What if we're using a cache with Redis at the edge. Would I be breaking GDPR laws if a EU user was traveling outside the EU and this triggered a cache into a Redis outside the EU?
What is considered sufficient security to store email addresses of our users? Should I be encrypting email addresses in the database even though this would be a massive pita and would prevent certain features from even existing?
Etc.
I could be here all day with lots of nuances.
Every time I read more on this matter it opens up a can of worms.
Disclaimer: this is obviously not legal advice, but I have been involved in similar GDPR adventures at my company.
> Does that mean I should be looking to host my DB with a non US company?
Yes, if you want to isolate yourself from any ramifications in the Safe Harbour/Privacy Shield/Paper Tiger #3 diplomatic processes.
> Does signing a DPA and putting some clause in our privacy terms be enough to be compliant?
Probably not (assuming you're referring to a DPA with a US-based company), but not having a DPA is not an option. In any case, the fallout from a total breakdown of transatlantic data transfers will be sufficiently large that fines will probably not be given without sufficient notice.
> Would I be breaking GDPR laws if a EU user was traveling outside the EU and this triggered a cache into a Redis outside the EU?
No, unless your outside-EU Redis is controlled by a different company than the inside-EU Redis. In which case you should sign a DPA with the outside-EU provider as well, with the same caveat as above.
> What is considered sufficient security to store email addresses of our users? Should I be encrypting email addresses in the database
No, but you will want to set up data access auditing for such fields, and possibly something like dynamic data masking so employees can not easily access the raw data. Normal at-rest data encryption of the entire datastore (and backups!) should be sufficient.
> Yes, if you want to isolate yourself from any ramifications in the Safe Harbour/Privacy Shield/Paper Tiger #3 diplomatic processes.
But if said US hosting company doesn't have the DB password then would this also apply? Do you think it would change anything if the data was encrypted at rest?
Strictly speaking, if said hosting company has access to the unencrypted data store they don't need any passwords. And if said hosting company has access to the encryption keys, any encrypted data store might just as well be considered unencrypted. So your question then becomes: how much effort should we spend on making it hard for our business partners to exfiltrate our data?
The problem with these kinds of questions is that the GDPR does not define any threat models, it only mentions "proper processes" and "adequate safeguards". Whether active subversion (by law or by greed) by your service provider should be included in your data loss exposure/risk assessments is very much an open question. At my company we decided to exclude such questions from the GDPR compliance process, and only include these scenario's in the threat models for our security assessments (note: that's not to say they are treated in isolation -- the results from our security assessments do inform our GDPR decisions like which data can be hosted where, but we do not repeat those same risk assessments in the GDPR survey).
To give a more direct answer to your question: I would consider encryption-at-rest a minimal requirement for a company hosting our internal data. Regardless of whether they're inside or outside the EU, and whether we're looking to host internal data, sales data or customer data; not being able to offer encryption at rest would mean my company won't use your hosting services for non-public data. For us, this specific ability is a supplier maturity test: if you haven't given serious thought about securing your customer's data, maybe we shouldn't be in business together.
But that decision is driven more by a defense-in-depth strategy about overall data security than by a specific GDPR requirement.
Encrypted at rest or not, the hosting company could easily dump the encryption keys out of memory while the server is running. If you're an American citizen, the government can just directly go after you or your company. If American law enforcement can get access to the data (i.e. by plugging the server into a UPS and carting it out of the data center) you're violating the GDPR at the very least; both attempts at skirting around the lack of American privacy guarantees were defeated by the American government refusing to provide sufficient data protection laws for European citizens, after all, choosing to uphold the PATRIOT ACT (and other such laws) over the digital business of EU customers.
Something as simple as a database password definitely doesn't fly as far as I know based on reading through the GDPR. Maybe it's legal if you apply enough tricks, you should consult a lawyer if you want to know your workaround is sufficient.
However, by default, storing PII of EU citizens (+UK citizens, I believe, they've implemented the GDPR before they left) with American companies is not legal. I can see how in theory a remote disk drive with fully end-to-end encrypted traffic (encrypted inside the EU, merely stored abroad, the decryption key never leaving the EU) may be allowed, but if the data gets decrypted on the American end I'm pretty sure you're out of luck. Otherwise, any form of TLS would be enough to avoid the GDPR, and that's definitely not the case.
Encryption at rest doesn't protect you. In fact, may even be legally required, regardless of where you store your data. The GDPR doesn't specify any exact security measures, but you do have to try your hardest to secure any PII you may process or store and encryption at rest is one of the easiest steps you can take to do so. You should make a conscious decision of what data may leak to where, the impact of the leak, and ways to counteract such problems.
In this case it's not enough just to be GDPR compliant, the website admin has to have Data processing agreement with the CDN, which you won't get from a free CDN such as JSdelivr.
It's complex because 'personally identifying information' is not a thing outside the digital. You can't enforce these rights on physical businesses for exampple (e.g. can't request from your local bakery to forget that you existed)
You can request they expunge all records of your purchases.
Not exactly a new idea either. Doctors have been subject to rules around record keeping for a long time. Its not really all that different between physical and digital - the cost of making and (ab)using records is just way lower in digital.
Sure, but the same thing applies in the digital world. If you're an important customer, its likely some employees know information about you. You can demand the company erase records, but you can't erase it from the employees' mind.
While the sibling comment has answered on why this is nothing like social media or video games, I do wish that the energy cost of these activities was taken into account more often. Video games in particular have become massively wasteful. Just downloading these 100GB behemoths expends useless energy. And everyone is pushing for 8K 172FPS games. Why? Just why?
And yes, before you answer, that applies to any hobby you can think of. You won't be astute by pointing out that e.g., car enthusiasts are similarly wasteful.
