Could the Swedish government require a VPN to start logging user activity? This question is basically the same as this question, but for Sweden instead of the United States Could the US government force a VPN provider to start logging? If the government asked a VPN that was operating in Sweden to start logging user data, would the VPN operator be obligated to do so?
A VPN operator has to follow the laws in the country where they operate. If the laws in Sweden say that a VPN operator must keep logs of user activity, then they have to keep logs of user activity. If it makes you feel better: There are two kinds of VPN operators. Those that say they log, and those that lie about logging.
Since your consent is not required in Texas, revocation is irrelevant. Restrictions of use of recordings flow from the legal nature of the recording itself, so there is no provision saying, for example, that only one party needs to consent for just recording, but all parties must consent to make any use of the recording. Since these laws were devised to regulate the practice of wearing a wire and collecting evidence of crimes, requiring consent from all parties would be counterproductive to the purposes of the law. You could try drafting a contract where you pay people to not record you (anybody who doesn't sign, you shouldn't talk to them), but enforcement could be tricky, so I would not try a DIY contract: get a lawyer. You would have to show that you were harmed by them making an unconsented recording. It should be in the form of a contract where you give something of value in exchange for something of value, which is a thing typically enforced by the courts. Also bear in mind that even in an all-party state, if you know that you are being recorded, you cannot just say &quot;I do not consent&quot;, you have to stop talking. Continuing to talk when notified that there is or may be a recording constitutes implied consent, which is why on the phone companies often announce via recording that the conversation may be monitored, and they do not ask &quot;Do you consent&quot;. By not hanging up, you consented.
It is probably illegal under Indonesian law for you to launch a cyber-attack on a website that you believe violates Indonesian law, just as it is illegal for you to shoot a person for fraud. The Indonesian government reserves the right to judge guilt or innocence, and to mete out punishment, within Indonesia. It is definitely illegal under US law, also UK law and so on, to launch a cyber-attack on a website for some reason, so you can be prosecuted under the laws of that nation. You should then be concerned with the Law on Extradition (1979), noting that there might be a treaty but also Indonesian law allows extradition on the basis of the interest of Indonesia (as judged by government officials). Indonesian nationals do not enjoy immunity from extradition (as is the case in some countries). There is no extradition treaty between Indonesia and the US; there was one between the UK and Indonesia but I cannot determine whether it is still in force.
No, you do not need to show a privacy policy just for running a publicly accessible server, as long as any traffic data such as IP addresses is only used as strictly necessary for providing the service requested by the user. The background here is that while GDPR is a very general law, the ePrivacy directive (ePD) provides more details for telecommunication and information society services, which also includes SSH servers. Per ePD Art 6, traffic data may be used (1) for the purpose of the transmission/service or when the data has been anonymized, (2) for billing purposes, or (3) for marketing or value added services, when the user has given their consent. Information about the processing is only required under ePrivacy for cases (2) and (3), but not for processing that is strictly necessary. Now the tricky question is under what circumstances you can log (failed) log-in attempts or use tools like fail2ban. One argument is that such measures are strictly necessary to ensure the security of the communication, but these measures are evidently not necessary for performing the transmission in the sense of ePD. There are a few ways to resolve this: necessity has to be interpreted more broadly, and security measures are indeed necessary. For example, ePD Art 6(5) mentions fraud detection, without authorizing it explicitly. an IP address is effectively anonymized in the sense of the ePD since you do not realistically have means for linking the IP address to any particular person. This is a fairly weak argument, but could be supported by GDPR Recital 26 which defines anonymous data. Counterpoint: IP addresses are online identifiers which are explicitly included in the definition of personal data in GDPR Art 4(1). an IP address is not just traffic data that falls under the ePD, but also personal data that falls under the GDPR. When the IP address is merely used to make a transmission, it is not processed as personal data and only ePD concerns apply. But when we process it to ban the IP, it is processed as personal data under a legitimate interest. This processing does not fall under any of the categories from ePD Art 6, so that only GDPR concerns apply. These include a requirement to inform the data subject about the processing at the time in accordance with GDPR Art 13, which could be satisfied by displaying a link to a privacy policy in the course of the login process. For a legitimate interest argument, it also depends on the expectations of the typical data subject. Since some security measures such as security logs are normal and should be expected, a legitimate interest argument is likely to be strong. I think this is the correct conclusion, even though the “it's not traffic data, or at least doesn't fall under the ePD” argument is quite weak. It hinges on the assumption that security measures are not “value added services”. This fits the intent of the ePD, but not the actual definition of value added services. In any case, you do not need to ask for consent unless you're required to obtain consent e.g. under ePD Art 6(3) or because your processing of personal data relies on consent as the legal basis per GDPR Art 6. It also has to be noted that ePD has no immediate effect, but has to be implemented by each EU member state in national law. These laws can provide more specific guidance.
Not that I am aware of. A person who 'owns' a domain is entitled to utilize that domain including for the purposes of receiving emails. With physical mail, it is a crime in most countries to intentionally interfere with mail that is not addressed to you. For example - Australia. However, this is statute law and as such does not extend to emails - even if it did, if you own the domain then you are the person to whom it was addressed. I note that you seem to misunderstand "confidential" - this only arises in the context of a special relationship between the person transmitting the information and the person receiving it. Usually this is a contractual obligation between A and B but it can be imposed by law (e.g. doctor-patient, banker-client, lawyer-client, GDPR etc.). If A sends confidential (as between A &amp; B) information to C, C is under no general obligation to keep it confidential if C has no relationship of confidentiality with A or B. If C discloses it and B suffers damage, B sues A for breach of confidence (or the government prosecutes A for breaking the law); B has no case against C. For your situation, where B has allowed A to send the information to an obsolete address then B has contributed to the breach to an extent that B would be extremely unlikely to succeed in a suit against A.
Is it actually necessary for businesses (such as a Small Town News USA Inc) that do not reside in EU to care about GDPR? Only if they offer goods/services to or monitor behavior of people in the EU (Art. 3(2)). Note that: having a commerce-oriented website that is accessible to EU residents does not by itself constitute offering goods or services in the EU. Rather, a business must show intent to draw EU customers, for example, by using a local language or currency. If it is then how (and by whom) would compliance be audited and/or enforced? Supervisory Authorities will care of it.
The GDPR only mentions cookies once (Recital 30). (It says that cookies are personal data if they are associated with natural persons.) As far as cookies go, nothing has really changed since 2002, and the exception granted in the EU cookie directive Article 5(3) is still valid: This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service. If your site complies with the 2002 directive today, it will be GDPR compliant. All the "EU Cookie Law Compliance" plugins I've checked out let the admin configure the site to comply with the 2002 directive, and most let you choose between implicit consent (which is, and still will be, OK if you or third party services do not use cookies for profiling or to collect personal data), soft consent, or hard consent. The latter is however mandatory if you or third party services use cookies to for profiling or to collect personal data. However, if at least one of your cookies are used for profiling (and if you use Google analytics, you are), or if they are used to collect personal data, the exception from explicit consent quoted above does not apply and implicit consent (i.e.: "continued use of the site amounts to implicit consent to the use of cookies") has never been legal for the site. So while nothing has changed since 2002, there is a lot of misinformation about cookies floating on the Internet, and a lot of sites have their cookie banners set up wrong. You may want to do a new cookie audit for your site to verify that you comply with existing legislation.
It is the data controller's responsibility to respond to data subject requests. If you provide a B2B service, you are most likely a data processor who only acts on the controller's behalf, on the controller's explicit instruction. This will depend on your contract with the controllers, your customers (see Art 28). Typically a processor would merely forward any data subject requests to the controller. Only if you are contractually obligated to serve data subject requests would it be possible for you to respond directly. If a processor were to fulfil a data subject request on their own initiative, that would arguably be a GDPR violation. However, the processor has to assist their controller with compliance per Art 28(3)(e), e.g. by implementing an admin interface through which the controller can service GDPR requests. The core issue here is that controllers and processors have slightly different obligations in order to be GDPR compliant. Controllers owe compliance to the data subjects, but processors only act on the controller's behalf and owe compliance to their controllers – they have no direct relationship with data subjects. Assuming you were a controller, then yes, I would assume you would have to decrypt any data that you are able to decrypt in order to fulfil a data subject request. Access requests can only be denied if: Art 12(5): they are “manifestly unfounded or excessive” (which the controller has to demonstrate), or Art 15(4): the access would “adversely affect the rights and freedoms of others”. Art 11(2): the controller can demonstrate that they are actually unable to identify the data subject so no data subject rights in Art 15–20 apply. A request is not automatically excessive just because it will require substantial CPU time, this exception is more often triggered when data subjects request the same data very frequently (e.g. every week). You are not required to provide or search data that you don't have access to (e.g. E2E encrypted data). Your use of per-field encryption is a very strong security measure (depending on how keys are managed). But GDPR is not about achieving maximum technical data protection, but merely requires appropriate safety measures (see GDPR Chapter 4, especially Art 32). Asymmetric encryption of small fields within a database is unlikely to be appropriate, taking into account the cost of processing and the data subject's ability to exercise their rights. A different security measure to ensure that every business only sees the correct data would be through testing and code review of your SQL queries, and full disk encryption of the server storing the database. In practice, asymmetric encryption is most often just used to encrypt a symmetric key, which is then used for the actual data. But which measures are appropriate also depends on the risk to data subjects – your approach could make sense for very sensitive data. Art 14 does not play a role here. It is about transparency of processing: that you need to (a) notify the data subject that you're processing their data, if feasible, and that you (b) provide information about this processing, usually in form of a privacy policy. Art 14 is the pendant to Art 13, which applies when data is obtained directly from the data subject. The Art 15 right to access and the Art 20 right to data portability are distinct from the right to be informed. In any case, it is the controller's responsibility to fulfil these rights.