"Controller and processor
Data controllers must clearly disclose any data collection, declare the lawful basis and purpose for data processing, and state how long data is being retained and if it is being shared with any third parties or outside of the EEA."
I don't see the word "personal" in this sentence, only "any data collection". It's clearly not in the users' interest/benefit to activate this data collection, and not required for the normal functioning of the browser/websites. So activating this silently is minimum _very unethical_ and probably illegal, but I'm not a lawyer.
A rather disappointing read. I was expecting an analysis explaining why there is this trend towards very sparse interfaces, or practical ways of designing interfaces that are denser in the face of design trends that are pushing all product teams to do ever more spacing out.
Instead, what I found was a reminder of the ‘laws of design’, which are certainly interesting, but which are only tangentially linked to this drift (in my opinion); and to take the most extreme example of sparse interfaces (the Bloomberg Terminal), without really any concrete elements that could help bring a little density back to our user interfaces.
...not to mention what ends the article, a lunar explanation along the lines of ‘Google's very high stock market valuation compared to Yahoo can be explained by the lack of density of its home page interface’ - really? Come on.
Agreed. Seems like a long winded lead up to what reads to me like a mildly condescending Gestalt 101, followed with the same examples I've seen in countless other blog posts over the last 15 years and very little in terms of actually discussing design trends.
Well, Google lost against Oracle too, so it appears a mere API specification can be closed down arbitrarily; than is the world we live in. Unless the US gets a lot more tech literate and open minded judges and officials, I doubt that will change for the better. And, looking at their presidential candidates… well.
The court decided the opposite--that APIs are copyrightable. However, the Supreme Court ruled that Google's usage was fair use, so I would agree that Google mostly won. The Supreme Court didn't consider whether APIs are copyrightable (the lower court ruled that) because Google would win regardless because it was fair use.
So I'm not sure it matters much whether APIs are copyrightable when what Google did was ruled fair use. I'd prefer if the courts ruled APIs weren't copyrightable, but I think it was still a good result because doing what Google did probably covers about any use case anyway.
I wonder if making a device which uses Threads could be considered fair use in the same way, because implementing threads is required for interoperability with many devices.
The Federal Court took up the appeal from Alsup case, accepted Oracles arguments that copying headers & using then same variable makes made the Java reimplementation a copyright violation (incompetent losers), sent the question of fair use back to a jury trial, the jury decided yeah it was fair use, the Federal Court ignored the jury and decided to ignore everyone hollering at them that they were being idiots & ruled for Oracle anyways.
Then the Supreme Court ignored the copyrightability aspects & ruled for a Google on some fair use grounds.
I've skimmed the write up from the ever excellent always recommendable Mark Lemley, Interfaces and Interoperability After Google v. Oracle, and really hope I can go a bit deeper into the history & trial at some point. Section 2 The Long Saga of Google v. Oracle starts on page 27 of the inner pdf. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3898154
It's been incredibly disappointing watching courts like the Federal Circuit be so unable to handle even basic technical matters with even an iota of comprehension, having them bungle up things so badly in the face of so much easy to rely on precedent. Being sweet talked by Oracle's lawyers into believing a header file is anything greater than interface definiton is either incompetence, or some really vicious pro-business hellworld shit.
Governments have no problem allowing de facto specifications to be closed. 5G is heavily patent protected, for example. MPEG is heavily patent protected.
Typically patents "essential" for a standard are licensed on "fair, reasonable and non-discriminatory" (FRAND) terms. But you do still have to go and pay for the license (sometimes from all the individual companies that have patents, sometimes from a consortium that represents the entire patent pool for a standard).
Here in Paris (France), I always use my credit† card, for everything from a drink in a bar to groceries to burgers to whatever. Most of the time, I use the contactless feature of my plastic card (works for anything under 50€), and sometimes, using my phone using Google Play, which is linked to my card, but doesn't have the 50€ ceiling for regulatory reasons.
I used to carry some cash for my nearest automatic laundery machines, but even that one now features a contactless payment dongle, so it's nearly useless for me.
† I say "credit card", but most plastic card WE carry on France are actually debit card, i.e. there is no specific credit card balance to top or anything, it's directly withdrawned from your account. (There is something hybrid called "differed debit card", that mimic some of the credit card experience, but it's basically buffering your withdrawals, without any "true" credit happening).
I think it's relevant for Hacker News, as Nintendo uses copyright laws to restrict drastically how their games can be played in tournament; for now, it seems to prevent any small tournament to generate any money — even selling food (!!) during the tournament — without becoming a fully fledge organisation and acquiring a license from them… with a lot of additional, specific restrictions (not allowing mods for example, which is not anecdotal for some version of Smash).
Nintendo wasn't helping the e-sport scene before, but with those move, I think they are now actively trying to kill it in its current form.
At first, I thought it was a good exercise (and it still is), but going through the result [0] made me more skeptical.
It is... slow? I mean, Internet Explorer slow. Maybe I'm spoiled by the level of responsiveness of application-style web interfaces, but opening an album or returning to the library feels slow. Is it because I'm browsing from Western Europe and the application is hosted in the USA?
I'm used to browsing multi-page apps that don't pretend to be apps, and having a 500ms load time after a click is expected and feels right. But waiting the same time for a click in a page that looks like an app makes me uncomfortable. It's weird - is this the Uncanny Valley again?
Looks like the enhance-styles.css doesn't get cached properly and gets requested on every route. The browser then waits for 500ms for a response from a server, likely due to increased web traffic.
An issue which could have been avoided by using a SPA :D
the main page loads fast but the interactions are slow, like there's some artificial delay
the 500ms estimate above seems about right... it should be much faster. Navigating from one static page to another should be sub-100ms assuming the server is on the same continent
> Was the Google self-driving car thing vapourware? It never went anywhere.
Well, it goes somewhere: people are actually being driven around Pheonix, Arizona [0] using those cars. It's just that it is not named "Google self-driving cars" any more: it was spun into its own company, Waymo [1].
And the EU is actively working on creating a new ePrivacy Regulation [0] that would explicitly tackle the explosion of cookie banners.
> Simpler rules on cookies: the cookie provision, which has resulted in an overload of consent requests for internet users, will be streamlined. The new rule will be more user-friendly as browser settings will provide an easy way to accept or refuse tracking cookies and other identifiers. The proposal also clarifies that no consent is needed for non-privacy intrusive cookies that improve internet experience, such as cookies to remember shopping-cart history or to count the number of website visitors.
Unique install per user per year.