Their archives would be an AIâ(TM)s wonderland to feed on

Technically the website didnâ(TM)t share user information, but provided code (the font include) that made the userâ(TM)s browser âoeleakâ data. So the term âoesharingâ was interpreted very loosely. You can expect that to be subject of the appeal in an attempt to define that more narrowly. I could imagine browser manufacturers getting dragged into this as well - maybe a permission prompt like access to audio/video? If users then disable it for annoyance⦠Like in a good game there are a few layers to come: - OLG (appeals court) - BGH (Federal court) - EuGH (European court) We havenâ(TM)t seen the last of it

Nope. According to GDPR you (the website operator) need an agreement with the CDN about data processing that is compliant to the rules. Hard problem for free/anonymous CDNs.

When you dig into this -> the story doesnâ(TM)t check out and is a fact free propaganda piece including fake endorsement

Commonly known as: the outdoors with phone switched OFF

Look who is in the copyright alliance. Tells it all. Copyright was intended and designed as TEMPORARY exception to the higher public good. It should return to this

The fashion industry eclipses the music industry by more than a magnitude (that's more than 10x ). Sources: https://www.statista.com/stati... https://www.statista.com/outlo... How can that be? Fashion has NO copyright protection! That's the reason why e.g. Louis Vuitton prints their logo (which is a trademark) on all their goods. How it works, see here: https://www.ted.com/talks/joha... In conclusion: Ask your lawmakers to end copyright for music! It works for fashion, it will work for music. Keep the lawyers out of the creative process!

Nonsense. The only real answer to OK Boomer is a big laugh. And a hoodie: https://shop.spreadshirt.com/n...

Well researched news: The Economist Deep well of knowledge O'Reilly's Safari Make version control well: Github

Bio data is less "something - only you - know", but, after a few breaches, "something freely traded on black markets for anyone who pays to know"

Except being unable to change the "something you have" makes it easy to be compromised. Someone steals a password database or the 2FA key seeds, you reset them. You can't reset your bio data.

Matching bio data isn't an exact 1:1 match. The mechanism is a proximity comparison. So the original data can't be protected by a one way encryption. Therefore it is way easier to steal that information for reuse. After all any biometric reader attached to a personal device can be simulated by an attacker and the stolen bio data fed in directly - so it is even easier than any of the current 2FA (the use case for readers in protected locations, think doors, is only slightly better). In summary having a unchangeable second factor lowers security, especially when the second factor can't be protected properly #badidea

Flawed solution: - can't scan for important pieces - no fast forward ... but most of all: if you have an international team that communicates in English as the second (or third, fourth) language it is, paired with line quality, almost in-comprehensive to decipher. Chinglish, Singlish, Gerlish, Thailish.... just to name a few.

You got offline editing, version control and variables.

and get to know it later :-). Fast here: your prototype creation, not primary the database I/O. The general comments are right: there is no one-fits-all solution and the database might change. It looks very much like you also haven't decided on the server platform: Ruby, PHP... you could look at node.js or vert.x too - server side JavaScript is at least neat for prototyping (I'm not making a statement that is is *only* neat for prototyping - that's a completely different discussion). We did a number of super rapid prototypes with datasets roughly in the range you describe using CouchDB (not CouchBase!). There we took advantage of CouchApps - the ability to store the application itself inside the database - works like a charm when replicating data and you need a http server (Apache, NGix) for the URL mapping (which is already kind of optional) and CouchDB. You can authenticate with OAuth or via the Webserver and it replicates - so you can have local data easily (gold for testing). Since you can specify the direction I usually replicate all data from the server into local, but not the design. So I can try new app features local against the live dataset. It also does Map-Reduce using JavaScript. Give it a shot. If it can handle the data from CERN you also have quite a growth path. One fun project we did: run it on a Rasberry Pi to collect weather data from Arduinos all mounted in a small sail boat (the Pi in the cabin, the Arduinos on the masts). Occasionally when the Wifi or 3G shield picks up a network, it replicated back to a cloud server.