smu

I fail to see the difference. Financial debt is also a brake on future activities, in the sense that you have to pay back with interest, so less funds are available for other activities.

So in your words: it makes this one iteration quicker, but slows down the next one...

Both times: yes and no. They both are indeed considered personal data, but they don't always have to be disclosed (as disclosing might harm others)

Actually, when someone is identifiable with a couple of pieces of data, that becomes personal data. For example, if you would be the only Paul Smith on earth, we would consider that personal data. If you are the only Paul Smith in the US and the context reveals that we are talking about someone in the US, those 2 pieces together are personal data (and so on).

That is what they mean with "indirect identification" in the link provided by jdietrich.

IMHO, this is a great insight and result!

See my answer above.

A couple of points to answer your question:

1. Yes, when exercising your "right of access", companies would have to send you all the personal data they have on you, except when disclosing this information would harm others (ie: notes of your manager about your performance or the example you gave) The exception does not mean that they can blankly refuse to give you any data, only the "offensive" part must be refused. By definition, that is still considered personal data however. As M2Ys4U mentioned: inferred data is also personal data.

2. there is a case where you don't have to provide all information: the right of data portability only applies to data provided by the data subject.

3. Someone is referencing article 14 below. That is not the same as giving access to data. Article 14 specifies how a data subject must be informed about processing of his data when you've received the data from someone else. For example: you've received someone's info from a recruiter and you now want to process his data to see if this person is a valid prospect. The article works together with article 13 (how to inform a data subject on what you are doing with the data he gives to you directly). Together, these articles are the reason for 50% of the privacy notices of the last couple of months :-)

That’s very interesting. I was under the impression that O-1 visa require verifiable world class talent (such as making the olympics in your discipline). Could you elaborate on what the bar is to be eligible for O-1 visa?

And as an added bonus, your experiments are more reproducible. Kudos!

This is mentioned in the recitals: you can request additional identification, in fact you should if you can't identify the subject [1] and if you can demonstrate that you can't identify the data subject (with reasonable effort), you don't have to comply to the request. [2]

[1] https://gdpr-info.eu/recitals/no-57/

[2] https://gdpr-info.eu/art-12-gdpr/ (point 2)

Sure thing, that's described in articles 44-50. In short:

1) if the EU has declared a country "adequate", you can transfer data (there is a list of adequate countries. Canada is on it, the US with Privacy Shield too)

2) in absence of an adequacy decision, there are other possibilities: binding corporate rules (internal rules for data transfers within multinational companies[1]), contractual arrangements (for example, the EU approved clauses), adherence to a code of conduct with a binding commitment (look at this like some kind of "privacy certification")

3) Finally, if the above are not possible, a transfer is still possible if the subject gives consent after being informed of all risks.

So, for the sake of debate: I would go with either binding corporate rules (in case of a multinational) or contractual arrangements.

[1] https://ec.europa.eu/info/law/law-topic/data-protection/data...

An invoice is either a contractual or legal obligation, which takes precedence over the data subject rights. Even if you are asked to destroy the subject personal information, that information should never be included and is against the law.

Actually, I was trying to point out ways to not have to remove/prune your logs...

In lawyers terms: a payment apparently is just a contract. So you can store the data needed for the payment under that legal basis.

IANAL

I'm pretty sure the hospital in the developing nation doesn't sell in the EU, so they don't need to comply.

Phew, crisis averted!

It's very unlikely your static page contains personal data that would be ok in the US but not in EU.

If you're referring to logging, there are some good responses in this discussion on how that will still be ok.

In addition, you can store the IP address if you want to use it for infosec (such as, finding out who to block in case of a ddos attack). See https://gdpr-info.eu/recitals/no-49/

The recital also mentions "accidental events that compromise availability, integrity, authenticity,..." That seems to cover debugging for me. No need to ask for consent.

To do certain analytics like page count, you don't need the IP, so that seems ok for me. To track individual customers however, that's something else.

PS: according to GDPR, a hashed IP will be "pseudonimisation", not anonymisation because you can have a key to go back to the original value. True anonymisation removes all info (the IP in this case)

UPDATE2: According to MIVB (responsable for the metro), not confirmed: 15 dead, 10 heavy wounded, 45 wounded.

UPDATE: Fire department is now reporting 10 dead in the metro. No additional details for the airport.

The Dutch (Flemish) news just confirmed. Currently 13 dead in Airport, 35 heavy wounded. In the metro, 0 dead. There are wounded but unclear how many.

Belgium is shutting down: No trains or metro in Brussels. Government asking people to stay where they are in the whole country.

Police is looking for suspicious packets. The prime minister is scheduled to give an update in 20 minutes (around 11:30 AM Brussels time)

I'm also in Belgium and following the news. Only one mention of possible shots fired so far (a while ago). It does not seem likely at this time (eye-witness accounts in airport not mentioning shots fired)

Presuming your "productivity" stays the same, you would either have 16 releases of size "1" after two days, or 1 release of size "16". Either way, the size of the code to examine would be the same, right? You would still have the benefit of getting the new features faster to the user, so I would say quick releases are still beneficial.

In your situation, I would look for ways to detect the issues earlier. Ideally, you know about it before the user does (which is easier said than done, I know). Added benefit of this: quicker feedback will help you pinpoint the problematic release ;-)

Thank you for your comment! I want to add to it as a former pentester: it's absolutely painful to read about these nitpicky "the world is going to burn if you don't modify trivial security setting X that will destroy user experience". Not because these shouldn't be included in the report, but because the focus is wrong.

As strayptr, I would also include the trivial issues as "informationals" in the report as you do want your clients to know about these for a number of reasons. However, most of my time would go to hunting for severe issues, where I defined severe on some mental ranking based on "difficulty to exploit", potential impact,... In addition, these issues were also where most of my attention went to afterwards, because you need to explain and educate development, testing and business on the issues, why you think they are important and how to best/quickest fix them.

In my opinion, building up relationships and having empathy for your client is very important. I would always try to have a chat with development/test/business to get a feel of where their heads were at. That would help me both while testing (what is important to them? how did they develop it? what is their maturity?) and while reporting issues (they would actually believe me, I could help them rank the issues and they would allow me to brainstorm how to best mitigate the issues for their environment).

Depending on your personal situation and goals, cycling to work could be a solution. 12 miles works out to 20km, which for me would amount to less than an hour of cycling time with good equipment. As a bonus, you'll arrive home with an empty head and you'll already have exercised!

Can you recommend some online communities where they discuss trips like these?

Also interested (if I can get there on time)

Seems like you have an extra dot in your link. Should it be: http://grep101.com?

Out of curiosity: who else would be in contention for "best manager of the generation"?

I don't have the IP for the code so I can't copy it here, but what I did was very simple and the gist of it is described below:

The parser used regular expressions to recognise function definitions and calls in those definitions. I used file names as the function scope, this was good enough because there were no two functions with identical names in the same file. Function calls became the following terms: "calls(x,y,z).", meaning that function x in file y calls z.

These "calls" terms actually define a directed graph. If you google "prolog path through directed graph", there are lots of hits that will help you out. The following (untested) code should get you started:

    %there is a path if there is a call
    path(Caller, File, Called, [calls(Caller, File, Called)]) :- calls(Caller, File, Called). 
    %there is a path if there is a call to some function and there is a path from that function
    path(Caller, File, Called, [calls(Caller, File, A) | P]) :- calls(Caller, File, A), path(A, _, Called).

After that, you can find all possible paths with "findall/3" and check for existence of a certain known good/bad function with "member/2" (again, google is your friend)

Due to some properties of the code, this simple approach worked well enough for me. Hopefully this helps you out.

Indeed! During a security assessment of a large code base, I wrote a simple ruby source code parser that spat out Prolog terms. After that, it was a breeze to find certain kinds of logic errors, such as code paths that used user input before sanitation...

It's beautiful when it all works together, checking everything manually would certainly have been a PITA and would have resulted in a lower quality result.

Definitely an aha moment!

Are there other people here with heavy corrections that have undergone LASIK surgery?

I was always told that heavier corrections (I have about -10 dioptrics) were tricky because they would have to laser away to much of your eyes' "back wall". This would make the eye structure weaker which could result in eye deformation (bulging eyes?). Truth to be told: that sounded possible and scary enough so I didn't investigate further. I'm ready to be proven wrong :)

For future reference: When you run into a problem where you think that syntax errors are the cause, try to replicate the database on your own computer.

In this case, the database schema and the code to access the database is known. The errors that are thrown when trying to exploit it locally will help you find a solution :)

It might be important to note that government owned cameras are by definition pointing to public property (where everybody passes), whereas private cameras should be targeted at some private property (enforced by law, at least in some countries). If this distinction remains true in practice, it would at least seem that privately owned cameras are "morally" a bit more in their right. (You submit to the house rules when visiting vs being filmed when doing something that is nobody's business, like just passing by)

Regarding the "processing" argument in the original article. It seems to me that government owned cameras are a bigger concern, if we assume that they can provide a general combined view (while privately owned cameras provide a lot of isolated views).

EDIT: spelling