Are websites legally obligated to provide a non-javascript login page? I have read a couple times now that Websites are obligated to provide an alternative login page when their login form uses Javascript. I have not been able to find much resources on the matter though. (Google likes to present me with websites that discuss legal information that happen to have a login feature.) Are there any legal requirements for a website to have an alternative to a Javascript login form? I'm interested in answers from all over the world.
In the UK, the Disability Discrimination Act 1995 includes provisions which are thought to apply to websites, although as far as I know there is no case law on the matter. If a website's use of JavaScript makes it inaccessible to users with some disability, it may fall foul of the DDA. However, there is no law specifically requiring JavaScript-free versions of web pages.
You could include a notice that the forms are not legal advice, and you make no guarantees on their effects in particular situations, and that readers should use them at their own risk, and that they are provided "as is" with no warranties of any kind. You might also find websites that offer downloadable legal forms, or forms similar to the ones you intend to create, and see what disclaimers or waivers of liability such sites typically include. I am not a lawyer, and this is not legal advice.
Interesting that they don't give a source and also don't link to anywhere (such as Wikimedia commons). So I assume that content is google's own. So generally speaking: No, when no license is provided, that means you can't use whatever it is in a project of yours (whether commercially or not), because the &quot;default&quot;, when nothing is specified, is that no license is given. So unless you find a license that grants you a permission on google's own content, these sounds can't be used freely.
Under European rules (GDPR, ePrivacy), you only need consent here if you both access or store information on the user's device (such as cookies), and this access/storage is not strictly necessary for a service explicitly requested by the user. A session cookie is strictly necessary for providing a log-in functionality, so such cookies are unlikely to require consent. In contrast, cookies for measuring ad impressions are not strictly necessary for showing the website content. Necessity must always be thought from the user's perspective, not from the provider's economic needs. If you use one cookie for multiple purposes, you should analyze each purpose separately. Maybe setting a cookie does not require consent under one purpose, but accessing the same information for a different purpose could require consent. If you have to ask for consent, this consent must be in line with the GDPR's requirements in Art 7. Consent must be freely given, i.e. there must actually be a way to decline the consent without suffering detriment. Consent must be informed, i.e. the user must be told directly for what consent is being sought, without having to click through to a long privacy policy. Consent must be specific, so it must be possible to consent for one purpose while declining consent for another. An &quot;I agree to the terms of service and privacy policy&quot; checkbox cannot constitute valid GDPR consent because it fails all these criteria: I cannot use the service without agreeing, I'm not told essential information up front (you cannot expect users to actually read long privacy policies), and this is an all-or-nothing bundle that does not allow specific choices. If you do not have to ask for consent, you should still be transparent about your use of cookies, for example by providing a paragraph on this topic in your privacy notice. I think showing a cookie banner would be a bad idea in that scenario, since it could be confused with an invalid consent banner (no way to decline the cookies).
There is no US law licensing journalists or people who report the news, or requiring such people to identify themselves by legal name. Nor can there be under the US First Amendment. There is also no law requiring a person to identify himself or herself by legal name online. Some sites, including Wikipedia, have policies against having multiple undisclosed user IDs for the same person, but that is a matter of the site's own rules, not a matter of law. Any US law mandating this would again run afoul of the First Amendment to the US Federal Constitution. This article on Anonymous Speech reviews and cites a number of US Supreme court cases on the subject of anonymity, mostly in political contexts. This article from the Electronic Frontier Foundation (EFF) discusses the same general subject. Both articles mention that The Federalist (analyzing and advocating for the then-unratified US Constitution) was originally published under the pseudonym "Publis". The EFF Article "Court Recognizes First Amendment Right to Anonymity Even After Speakers Lose Lawsuits" discusses the 6th Circuit case of Signature Management Team, LLC v. John Doe in which it was held that an anonymous blogger who lost a copyright infringement suit could nonetheless remain anonymous. This page apparently from a Harvard course, lists and briefly describes several cases on the same subject. In Doe v. Cahill, 884 A.2d 451 (Del. 2005) an elected official sued an online poster for defamation, and sought to force the ISP involved to disclose the poster's identity. The Delaware Supreme Court ruled against this, setting a standard offering greater protection for such anonymous online speech than previous cases had. This answer is very US-centric. Laws in other countries are different. The OP has not specified a country or jurisdiction.
Sure, you can make such a request, but its not likely to help you. Scammers are criminals and don't generally care about GDPR compliance. Scammers are criminals, and won't just publish their real world identity. Serving them with a lawsuit will be difficult, especially if they are from outside the EU. GDPR lets you sue data controllers, but it's not worth it. You can sue for compliance (e.g. to compel fulfillment of your access request), and you can sue for damages stemming from GDPR violations. Compared to the damages you have suffered, a lawsuit is very expensive.
When integrating third party plugins, it is important to determine whether that third party is your data processor or another controller. When they are your processor, you need a legal basis for the processing purpose and need to have a suitable contract with your processor. When they are a data controller, you need a legal basis for the processing purposes AND a legal basis for sharing this data with the third party. When using Facebook tools, you have to read the fine print in their Business Terms. I will assume that when integrating the Chat Plugin, you and Facebook would act as joint controllers. Facebook would not be your data processor. So you need a legal basis for sending data to Facebook. Some information will already be sent merely by loading the plugin in the visitor's browser – and this will happen whether or not the visitor is a Facebook member. Two legal bases seem especially interesting: you might have a legitimate interest for loading this plugin, or you might ask for consent. A legitimate interest requires a balancing test between your interests, and the rights and freedoms of the data subjects. The reasonable expectations of the data subject will likely be a factor as well. Here, I would suggest thinking about the reasonable expectations of a visitor who is not a Facebook member. In most cases, when you rely on a legitimate interest you must also give the opportunity to object to further processing, i.e. to opt-out. You can base almost any processing activity on consent. This gives you a lot of flexibility at least initially, but you can't use the data for any other purpose, and must make it easy to withdraw consent. Here, I think that your legitimate interest balancing test would lead you to the conclusion that consent would be the more appropriate legal basis. But this doesn't mean that you need to show a consent banner to every user. Instead, I would suggest the following procedure before loading any third party plugin or embed (whether a Facebook chat, a Tweet, or a Youtube video). The point is that users are given an informed choice: do not load the content by default as a placeholder for the content, or in a popup when the user interacts with the placeholder, show the following information: what the purpose of this content/plugin/embed is that a third party provides the content who the third party is what personal data will be disclosed to the third party, e.g. IP addresses if personal data will be transferred into a non-EU country: information about possible risks, e.g. the US does not provide an adequate level of data protection where visitors can find further information about the resulting processing by the third party (e.g. the FB privacy policy) a link to more information in your privacy notice how visitors can revoke consent later if the visitor clicks a button such as “start chat” or “load content”, treat this as consent store the consent for later visits, e.g. in a cookie make it easy to withdraw consent, e.g. with an easy to reach button that opens a consent management tool So instead of asking for consent when your page loads, ask for consent just in time before they're accessing something for which you need consent. Background: In the Fashion ID case, the ECJ has found that the provider of a website that loads Facebook social plugins such as the Like Button is a joint controller with Facebook. So the website provider is responsible for collecting and sending personal data to Facebook through this button, but they are not responsible for what Facebook later does with this data. At least in Germany, it has long been standard that social plugins are only loaded upon consent, e.g. with a toggle next to the network's logo (news report from 2011). The list of information to be shown in a popup was modelled after section 3.3.1 “Minimum content requirements for consent to be ‘informed’” in the EDPB guidelines on consent 05/2020. Providing information just-in-time (just before the user takes a relevant action) and in a layered manner (key information directly, details in a privacy notice) are best practices suggested in the WP29 guidelines on transparency which were later endorsed by the EDPB.
We can't really know until the ruling is made. The Supreme Court might issue a ruling that encompasses all software APIs, or may predicate its ruling on this more specific situation, e.g. that because Oracle's library is so extensive its structure can be copyrighted even if that does not necessarily mean that any individual function signature can be copyrighted. They could also decide based on something unrelated to the heart of the copyright question - skimming through the petition for a writ of certiorari, they could make a decision based on the original implied license from Sun, for example. Hopefully their decision will answer the copyright question of function declarations completely, but it isn't required to.