HN user
It's an odd term, but one that inadvertently brings attention to concerns such as privacy and identity persistence.
Such concerns are far less obvious to laypeople when terms like "real-time modeling of traffic flows" are used. Perhaps, the choice of term is fortunate after all.
Sometimes it really shows that many early Wikipedia articles were someone's labor-of-love about a relatively obscure topic, and even today there's uneven levels of notability across the encyclopedia.
Instead of these hyphenated iron laws of transportation demand that no one has ever heard of that all say the same thing, the article of "induced demand" ought to suffice, and these formulations, if they exist original sources at all, ought to become references in that article's footnotes.
The clearest benefit of conferences for developers is networking and the "hallway tracks" -- the emergent discussions that arise after talks. The social processes of these are hard to replicate online. The asynchronous nature of online text chat, perhaps the most apt widely-deployed alternative, already lessens the urgency and spontaneity of the discussion. There are people who don't take advantage of the opportunities to insert themselves into emergent conversations, and unless their presence alone is a positive signal for the company, they're largely wasting their company's money.
The clearest benefit of conferences for sponsors is the potential lead between frontline-but-backoffice workers who work on a particular topic to the decision-makers behind them who can influence purchasing. Being present at conferences fosters passing familiarity of developers with the product, which helps conversations that occur between those developers and their bosses later: the emails from the higher-ups that ask "what do you think about Product?", and the off-the-cuff gut assessments that follow. Irrespective of the developer's initial reaction, name recognition of the product sticks around and often makes it to later rounds of evaluation and assessment.
This whole case is contrived, and both actors acted in bad faith, so the outcome will be troubling no matter what.
If Oracle wins, others can claim that their API is copyrighted and weaponize copyright law to sue anyone they don't want to interoperate with them -- despite the whole point of APIs being that interoperability.
If Google wins, it means anyone will be able to hijack the syntax, semantics, and interfaces of an ecosystem verbatim for commercial ends to promote an incompatible implementation, like they've done with Android. To protect against this, patents and NDAs will proliferate, and black-box organization and SaaS business models will solidify as the only (commericially) sensible way of distributing software.
In a JWS the header is integrity-protected by the signature if the alg isn't none. This is prominently noted in the specs and alg=none artifacts are referred to as "unsecured JWS". In a JWE the protected header is integrity protected by the AEAD cipher, because all encs must be AEAD.
The alg=none substitution issues happened because of bad usage of mediocre libraries. Other algorithm substitution can arise for the same reason. The invalid curve attacks were the ones that the spec didn't call out as a security consideration.
I support the arguments that say algorithmic agility is a bad idea and a new protocol with algorithmic agility shouldn't have come out at a time when other protocols (like TLS) were finally starting to catch on to this fact. But the JWT cat is out of the bag, and won't go back in: it's widely deployed and people are using it thinking it's solving problems they actually have. Education is the proper remedy.
The PASETO effort attempts to provide better answers and better design to an audience familiar with JWT, but there's also been an uptick in the kind of advice that heavily condemns JWT without supplying some migration paths. That latter brand of advice is harmful.
Most people use the JWT compact serialization, which cannot carry the unprotected header at all. If you're exchanging JWT compact tokens, the header is protected by the signature or the encryption.
Much of the ahead-of-the-curve, aspirational tech stack posts featured on HN are the blogging equivalent of Instagram-polished shots. On a personal blog they're equal parts self-expression and self-promotion; on a company blog they're equal parts deep dive and recruitment teaser. It's okay. Some readers will feel intrigue, some confusion, some envy. They'll wonder why they can't use those new tools at their work.
It's nice to recognize there exist developers who seem to stand apart from the vocal ones who make these posts, but they're not a single class. Some brag just as much, just in different circles. Some don't brag, but they do lots of good work. Some put out work that's not so good, and they may or may seek to represent their accomplishment regardless. The only factor they clearly share is their underrepresentation and their lack of attained popularity in talking about their work on social media.
As tempting as it may be, it's a big reach to conclude due to their underrepresentation that their tech stacks are conservative, or even dated; it's not a given that their work is solid and they're hard at work solving business problems given numerous constraints and office politics. Efforts to define this population by their rejection of shiny hype just perpetuates a kind of fictitious class divide between "fancy" developers and "plain" developers, when the real class divide is between management that is desperate for results, and IT workers that are desperate for empowered decision-making and resources. Businesses are under tremendous pressure, and silver bullets read about elsewhere carry great appeal. Transplanted organically by enthusiastic developers or by order of management, such solutions rarely work, because changing just a few inputs of a complex process won't deterministically give a better result. And mediocre results of a messy process make for a different genre of writing.
Maybe there's a class divide after all: between developers who are privileged enough to cook up all sorts of clever, custom solutions to challenging problems and can write about it, and those who spend their whole workday surviving the onslaught of nonsensical demands and deliver something mostly working in the end.
I'm a SoFi Money customer.
PayPal Cash Plus has a ton of features, but there's lots of fees [1][2]. You earn no interest. It's not a good deal, other than it being familiar.
Square Cash, now known as the 'Cash' app, is a strange hybrid of a P2P payment network and a spendable balance that gives a debit card and you can direct deposit into. You earn no interest. It's odd. It targets a hip young consumer who wants ease and convenience and doesn't know any better. It has... some... virtues? Just not ones that make it worthwhile to use it instead of some rival that earns interest.
Depending on your exact use-case, it will vary which one of these is ripoff-tier and which one is so-so. I have a low opinion on nickel-and-diming fees for convenience features, so I find the PayPal Cash Plus offering the most grievous. Square Cash just has a weird use-case that isn't my use-case.
[1] https://www.paypalobjects.com/digitalassets/c/website/ua/pdf... [2] https://www.paypalobjects.com/digitalassets/c/website/ua/pdf...
See the history of the Stabilization Act of 1942 [1] and Executive Order 9250. Wages were frozen by law, but not benefits, so companies began offering benefits, including health insurance [2] The next year the IRS decided these were nontaxable, until it changed its mind in 1953, only to be overruled by Congress in 1954 [3].
[1] https://en.wikipedia.org/wiki/Stabilization_Act_of_1942 [2] https://www.nytimes.com/2017/09/05/upshot/the-real-reason-th... [3] https://economix.blogs.nytimes.com/2013/07/30/the-question-o...
"Classic" ones: Schwab [1], Fidelity [2]. Vanguard recently announced they're discontinuing theirs [3].
New ones: Square Cash [4], PayPal Cash Plus [5], SoFi Money [6], Aspiration [7], Simple [8], unreleased and cancelled Robinhood product [9].
These couldn't be more different: one is ripoff-tier, one is so-so, while the rest are pretty good.
[1] https://www.schwab.com/public/schwab/investing/accounts_prod... [2] https://www.fidelity.com/cash-management/fidelity-cash-manag... [3] https://www.investmentnews.com/article/20190304/FREE/1903099... [4] https://squareup.com/us/en/legal/cash-ua [5] https://www.paypal.com/us/webapps/mpp/ua/legalhub-full [6] https://www.sofi.com/faq/#money [7] https://www.aspiration.com/get-account [8] https://www.simple.com/help/articles/goals/protected-goals [9] https://www.marketwatch.com/story/robinhood-quietly-stops-us...
It's disruptive as this kind of product moves downmarket, at least in the sense of mindshare and marketing, if not always in terms of customer segment. These accounts may be common knowledge among people who invest online and interface with brokerage firms, but others might not know about them.
The recent marketing tactic by newer firms is to convince people to migrate from checking and savings accounts, to catch the demographic that has (for whatever reason, presumably related to cashflow, lack of info, or generational anxiety) already decided that online investing may not be for them. Perhaps they'll change their mind once they're past your acquisition funnel.
I didn't see 'cash management accounts' on the list, but I think these are among the best products. They're not too common, but more are appearing now.
There's the classic ones that combine various investment products and slush balance that's insured by a bank sweep in the same interface, and the new ones that abstract completely away from the underlying storage of the money, and provide some familiar features (debit card, bill pay, ACH transfers) and perks (high interest rate, no fees).
The latter kind is a great, low-risk, low-effort store of spending money for people with unpredictable income and/or spending who have little time or cushion to invest in products with higher returns and need the liquidity. It's a compelling alternative to a traditional US checking account at a large bank, where most of this demographic has their money.
Tumblr's adult content ban was likely a last-ditch effort by Tumblr, encouraged by owner Verizon, to salvage some business value out a hectic social (re-)blogging site that seemed like a questionable fit even for the previous buyer Yahoo.
Verizon embarked on an ambitious effort to be a force in online content and display ads, so that they'd produce worthwhile content that would contribute to them running a bigger and more successful ad network. They bought AOL and its magazines to make it happen, and a few years later they acquired the content arm of Yahoo when Yahoo pivoted to an investment holding company.
Porn blogs were a big and visible part of Tumblr, but Tumblr's unwillingness to use coarse filtering meant that they were poorly policed. Porn blogs were overwhelmingly run by bots and hosted stolen content, they'd spam-follow unrelated accounts to game search engines, and they'd generally be a nuisance in every way, despite attracting a fair amount of viewers. The Apple App Store fiasco gave a convenient pretext to roll out the coarse filter to whack porn blogs and make the site more palatable for advertisers, but the collateral damage also affected erotica, art, sex-positive communities, and various LGBTQ communities. Meanwhile, ads on Tumblr have gotten a slight bit more frequent since the Yahoo days, but hardly any more relevant or less low-rent.
The author is clearly passionate and brings a lot of detail, but it was always my amateur impression that Walmart won primarily on footprint. They covered the country in stores, and not just the suburbs, but also rural America where the likes of Target and Kmart never ventured, and shops with much smaller selections and different formats were the norm.
I don't perceive Amazon as an 'unbounded' Walmart like the author does, but as an aggregator as thoroughly analyzed by Ben Thompson of Stratechery fame. They bootstrapped a destination with undifferentiated products, a broad selection, and convenience, and later bolted on a marketplace to further capitalize on the traffic. But the dynamics of customer-facing marketplaces are very different from those of internal ones like those of Walmart and McDonald's. McDonald's puts out specs and has suppliers compete for restaurants' buys, and Walmart and Costco have immense purchasing leverage with suppliers, this process results in optimizing the desired quality-to-cost ratio the retailer wants to target.
Amazon, on the other hand, is a free-for-all, where selection is overwhelming, products with obscure branding appear to rip each other off to the point where no obvious choice rises above, human curation is absent, reviews frequently appear gamed, prices change arbitrarily, products are gated behind Prime and are subject to obscure shipping math, and despite being long perceived as having low prices, pricing on products is now being used as a signal. Amazon is hardly anything more than a digital flea market, where Amazon is the landlord and some of the vendor booths are staffed by them directly. A wildly successful and profitable one, and one that draws marketshare away from traditional retail, but it diverges so far from the formula of retail that comparisons with them are of questionable value.
Not sure if the comparison to Conway's Law works. The key goal of layering is abstraction, so that one can be productive without having to know details about the layers below, but much of optimization is about exploiting details in the layers below for gain. Clearly, these goals are in conflict.
After posing a hypothesis, the post talks about security and process isolation. But the problems raised aren't in line with the hypothesis: the challenge in these cases isn't "insufficient communication" between the levels of the stack, but rather a discrepancy between the abstraction's actual behavior vs. a human's desires and expectations about big-picture topics.
These abstractions often compromised by information leakage through side effects that executing code can observe or deduce, leading to the class of vulnerabilities that have long been around, but have received far more attention since Spectre.
Protecting against timing attacks and other side-channel attacks requires the observable state of the system to not vary due to execution in a different security domain. Timing attacks are particularly frustrating, because processes can estimate their execution time even without external timers, so it can compare the time taken between different calls. Cryptographic operations often take special care to avoid leaking information through timing, but the same discipline isn't commonplace in system calls or userland code. And shared caches will leak info in timing but greatly improve performance.
Hardware isolation is an effective solution for curbing timing attacks for systems that don't communicate over a network. It's not sufficient in the case of networked systems, because the network and its connections form another source of observable state that's likely full of unrelated side-effects.
Discord hits a sweet spot of design choices that make sense for online friends occasionally intermingling with strangers on the Internet. It's free and has share-URLs to onboard into the product, it's pseudonymous so one can be known by a chosen persona, it's centrally hosted so DOS-attempts don't impact users' networks, but the management and moderation of channels and spaces is distributed. History is searchable, 1-to-1 conversations exist, voice chat is optional but effortlessly available.
IRC is the ancestor of this kind of chat, but IRC isn't as widely known as it was in past generations, it has connection privacy challenges, and has a less cohesive service identity and onboarding story that people have come to expect with the spread of centralized services. Slack is another modern, centralized take on IRC, but reveals one's email address, and multiparty voice chat is gated behind paid plans and limited in size. Gamer voice chat systems are decentralized and are lacking in text chat. Old instant messaging networks have been shut down, new ones either don't have desktop clients, don't have a good group voice chat, or reveal personal info. Skype was fine on all three and was a hangout tool for many, until Microsoft ran it into the ground.
It's a bit of a meme now that companies are putting out chat services yet no one can do them right. Surely there's economic forces at play, and rich media chat is probably expensive, but there's companies with very deep pockets who could run it as a loss leader just to starve their competitors, to commoditize their own complements. But cloud storage for individuals or video hosting like YouTube is also expensive, yet an upgrade path exists for users who want to pay. Google has thoroughly ceded chat to Facebook and still can't sort their strategy out, Facebook is just now realizing that they could tackle a more private chat too and they could satisfy that demand, Microsoft has morphed Skype into everything from Windows-integrated platformwide IM to a bad Snapchat clone and back again to a WebRTC shim, this time with a Chrome-only client. Asian apps capable, but are focusing on other markets and aren't as well known in the US. Telegram still doesn't have group voice calls. VC companies focus on the enterprise where willingness to pay is higher, amounts are higher, but use-cases are different.
I agree with the points raised in the writing, but it mixes automation, abstraction, and industry consolidation as if they weren't separate processes. As such, the transformation being described isn't an impending cliff, but an ever-present pressure of economic forces that affect all business all the time, and one is wise to watch for.
Automation replaces repetitive work with tooling and work that's more complex. Abstraction allows one to delegate to another for details, which may include choosing from a palette of pre-made options. Consolidation will come about as fewer independent players can sustain themselves in the market. Some will be out-competed by economies of scale, some will be starved by restrictions on intellectual property and lack of access to expertise.
This process has already played out for "small business websites", yet there's still lots and lots of web developers and web designers employed or freelancing. The current wave of WYSIWYG website generators is actually very good, and they have add-ons and integrations that make sense for their target market. But plenty of clients don't want to mess around in it, so they'd rather hire someone. This could be maker of the generator, or it could be an outside consultant. In either case, the person brings judgement, experience, and creativity, to tailor the deliverable to the needs of the client. These are skills resistant to automation, but not immune to abstraction and consolidation.
In the end, the antidote is the same as it always was: be adaptable, be personable, be resilient, and be resourceful. These are especially important in one is in a comfortable job shielded from most competitive pressure, because they will be the most surprised and unprepared if their current employment is made redundant.
1. Communicating clearly in 'business language' is essential when the junior developer interfaces directly -- not through an intermediary -- with business people and stakeholders. This tends to happen in heavily siloed BigCos, especially in places where IT is just a business unit among many, much more so than in SV or startups. But it's also a skill that one rarely has an opportunity to use in isolation, away from the pressures of estimation, project management, of implicit requirements-gathering by listening to business units segue to different business problem, and sometimes of fudging and obfuscation and make-believe falsehoods to soften the impact of reality. These are complex dynamics usually played at the senior team lead level. Most team leads know this, and don't subject junior engineers to this game with no help.
2. These sorts of high-level expectations tend to get peddled around a lot, not the least bit because it's both noncontroversial advice and a desirable baseline, but they aren't even always necessary. Often, the systems one will work on already exist, they already don't conform to an idealized model because of a series of fixes and mistakes made under pressure. These points are a stand-in for saying you should design and code in a way that future maintainers can make sense of what was written. Sometimes that's using patterns and strategies that are well known, instead of a contrived variation. Sometimes that's staying true to the existing design of the product and the codebase, because tacked-on parts in a different style will increase complexity of the whole.
3. Interfacing in the design and mechanical sense, and achieving that design consensus using interpersonal relations are really two separate skills, and once again it's reasonable to expect that consensus to be set not solely by junior staff between different business units. After all, interfaces and system boundaries ought to have business significance -- not only because of the implications of Conway's law, but also because interfaces and their outputs are often the only orgwide-visible products of the business unit. They must stand up to, or meet the challenge of future pressures such as planned re-use and enhancements, some of which will conflict with the intentions behind the original design.
Well, the people who dismissed the term 'serverless' early on as trite, misleading, and vague were proven right: these days it's a cloudy notion about something loosely cloud-related, such that posts like need to exist that can clarifying all the possible meanings with one-liners using real terms of art; yet the term clearly has cachet with technical-ish and nontechnical decision-makers as a Solution that unlocks Value and other more-good-than-bad outcomes that are bullet-shaped and made out of silver.
Players who jump on the term train are complicit in milking the confusion of people for gain. And that's perhaps much of the reason why we haven't unlocked the concept's value. To move forward, it would be useful to clear the air at the start, but the direction that consultants, customers, cloud providers, and developers will take the message is far from certain.
In a typical BigCo, much of the "soft service" processes are run by their own group, far removed from the reach of the automation implementers whether they're internal or external.
A top-down mandate to bring increased automation will require the implementers and the business unit to meet, agree on requirements, and exchange detailed information about the existing process which may or may not be formally codified. This process is frequently done without the involvement of frontline service workers, so the information being exchanged is done by people at least one step removed from the details of the work, and it just gets worse from there, like a meeting-filled, high-stakes variant of the telephone whispers game.
The opposite case is where a business unit develops their own highly computerized solution, but the process, when discovered, is unacceptable to the BigCo. The subject matter expert can seldom contribute technical artifacts into the sanctioned rewrite, so the rewrite becomes an imperfect facsimile, and the subsequent migration will cause issues.
In both cases, much of the conflict comes from the users of the software not being contributors to the software, in a broad sense of that word. And, service unit employees are often already tiered between process administrators and task executors with no obvious path of advancement between them, such that the frontline workers can be automated out of a job entirely. On top of the organizational barriers, this creates a structural disincentive against contributing to a solution.
Many people can and do go elsewhere, because an individual can have presence on multiple platforms. And while one's social graph in different platforms looks different and is missing some people they know, the network is both self-healing and self-fulfilling, in that it can be reasonably assumed that strong connections can survive irrespective of the network, while weak connections may not, and all connections that didn't survive will be retroactively redefined in one's mind as weak.
It's not like people genuinely use Facebook to discover brand new individuals (as opposed to bands or groups), whereas they'd frequently do that on Instagram, Twitter, or Tumblr. And for interests and activities like music discovery, live music, celebrity fandom, neighborhood activities, and classifieds, other viable alternatives do exist, even if they aren't packaged alongside a rolodex of all the people you went to college with, or your vacation photos, or some isometric farming simulator you used to play 8 years ago.
I don't know the economics terminology, but perhaps average people are just decent at exploiting opportunity? In this study a third party paid out the second-lowest amount to the bidders who bid the lowest amounts in return for deactivation. While no one competitor platform does everything of what Facebook's apps do, there are plenty of competitors they could make use of instead to replace particular single features or utilities of Facebook. The auction then becomes a game to bid an amount that's high as possible, yet still the lowest among the bidders, to actually win the bet. And instead, if Facebook raised prices from $0 to $1000 overnight, people would quit in droves, for the same reason: because dozens of comparable offerings exists at low or no cost that can take over subsets of the functionality in people's lives.
Given that airline overbookings use the same scheme to decide who flies and who gets paid and bumped to a certain, yet hazy-on-details future flight, perhaps this study simply tests humans' secret bidding strategies much more so than it tests the value people place on Facebook's utility.
One way to continue along this line of research would be to make people bid on giving up a much larger selection of social media services, with the exception of one, which would be their choice. They'd have to name their choice to keep. A second auction would then encourage them to name their price to give up that last one as well.
The author raises some good points about a few gatekeepers controlling the majority of the audience, but then condemns recommendation algorithms and believes no one has attempted to solve the discovery problem. How does one miss the obvious when it's right in front of their face?
Discovery is fundamentally hard because its success is judged by two parties whose interests align on paper -- for publishers to find a receptive audience, and for a consumer to find enjoyable content -- but the market is so vast that a missed match isn't just that, but often a match for a different pair. And consumer attention is vast, but ultimately finite, in that it suffers from oversaturation and requires novel and exciting experiences to stand out from a sea of similar offerings.
So platforms use recommendation algorithms to try and guess the sort of stuff every person likes, and try to surface content they're more likely to appreciate, instead of surfacing something completely random. Content that's brand new has no data on its audience, so a chicken-or-egg problem occurs where popular content can bubble toward its most fitting audience, often growing until it can't, while never-before-seen content languishes in a popularity vacuum, desperate for out-of-band help.
The classic out-of-band help is word of mouth. Sponsored, promoted content is a kind of in-band help, allowing platforms to make money and producers to jumpstart their exposure, but has the same structural properties as popularity: those most equipped have the potential to rise the most, while those least-equipped are disadvantaged once more.
People don't download Chrome because EdgeHTML-Edge sucks; they download Chrome because it's familiar, and ironically doesn't nag the person to enable half a dozen Microsoft's services one by one. There's two greater truths here: that some people are more comfortable using Google's services over those of Microsoft, and that the power of defaults matter, even when they feel skeevy to a part of the population. Google proved that defaulting to all the services enabled by default is reasonable not just with a discretionary application (like Chrome) but also when the user barely has any other choice on the device (like Android), and years of these defaults have resulted in a userbase that relies on them and seeks out the product for this reason.
It also shows that past precedent can lead you down a gauntlet of bad PR: Microsoft has tried to be pushy with many features of Windows 10 (telemetry, inking, online login, Cortana, always-online search) in the same vein that we've long seen from Google, but their strategy contrasts unfavorably against long legacy of a less invasive Windows. Google has pursued a policy of opt-out from the beginning, and by doing so they escape a fair bit a bad press.
Firefox has the worst of it: their users are the most discriminating, the hardest to please -- even if some of Mozilla's controversies were poor choices, the level of uproar was immense. Posts like this just encourage the migration of users driven by causes. This would be less of an issue if it were entirely community-supported, but Mozilla has paid developers and evangelists, and deriving revenues from a discriminating userbase is a challenge.
The relevant quote from this version [1] is:
"The definition of online content sharing service providers under this Directive does not cover microenterprises and small sized enterprises within the meaning of Title I of the Annex to Commission Recommendation 2003/361/EC and service providers that act in a non-commercial purpose capacity such as online encyclopaedia, and providers of online services where the content is uploaded with the authorisation of all right holders concerned, such as educational or scientific repositories. Providers of cloud services for individual use which do not provide direct access to the public, open source software developing platforms, and online market places whose main activity is online retail of physical goods, should not be considered online content sharing service providers within the meaning of this Directive."
[1] http://www.europarl.europa.eu/sides/getDoc.do?type=TA&langua...
They're supposedly under 500 employees, which is the EU threshold for small and medium enterprise. They prominently mention their small business status in their post. It's likely that their assertion is deliberate.
To add to my earlier, as a personal note, this is frustrating to me, because the text is clearly worded to target the likes of Google and YouTube without calling them out by name, while exempting pretty much all of academia, hobbyist sites, small businesses, intranets, and content platforms that don't actively promote and significantly profit off of their collection and curation of low-effort, low-remix, non-OC, verbatim reposts of someone else's copyrighted content.
Yet, through the lobbying of interested parties the message becomes deliberately muddled. Sites like Reddit spread the FUD because were it not for their status as a small enterprise, the letter of the law could threaten their business model of aggregating large amounts of user-submitted content and profiting off of ads surfaced adjacent to them -- ironically, the old Reddit before ads would likely be exempt entirely. They see this law as an existential threat and lobby against it; this I can understand.
What puzzles me is parties like the EFF and Wikimedia Foundation spreading the FUD. Wikimedia would clearly be exempt. What gives?
I doubt most of those people who've bought into the notion that small businesses like Reddit and nonprofit services like Wikipedia would be affected have read the relevant text, considering the text specifically says nonprofits and small businesses are exempt [1] from the rules of Article 13 (the takedown one).
I'm also puzzled by the people saying it's difficult to comprehend. The hardest part is mentally joining the diffs in amendments to the static copy before a document is updated. EU legislation is not nearly as weasely as US, and likes to use precise terms it defines earlier in the document. Such is the case with the terms 'information society service' and 'online content sharing service provider' [2], whose exact definitions are relevant.
[1] https://news.ycombinator.com/item?id=18488844 [2] search for 'Amendment 150' in http://www.europarl.europa.eu/sides/getDoc.do?type=TA&langua...
Original text [1], changed by amendments [2]. Relevant definition:
Amendment 150, Proposal for a directive, Article 2 – paragraph 1 – point 4b (new):
'online content sharing service provider' means a provider of an information society service one of the main purposes of which is to store and give access to the public to a significant amount of copyright protected works or other protected subject-matter uploaded by its users, which the service optimises and promotes for profit making purposes. Microenterprises and small-sized enterprises within the meaning of Title I of the Annex to Commission Recommendation 2003/361/EC and services acting in a non-commercial purpose capacity such as online encyclopaedia, and providers of online services where the content is uploaded with the authorisation of all right holders concerned, such as educational or scientific repositories, shall not be considered online content sharing service providers within the meaning of this Directive. Providers of cloud services for individual use which do not provide direct access to the public, open source software developing platforms, and online market places whose main activity is online retail of physical goods, should not be considered online content sharing service providers within the meaning of this Directive;
[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A... [2] http://www.europarl.europa.eu/sides/getDoc.do?type=TA&langua...
As usual with upcoming legislation, FUD predominates in the conversation. A reasonable person may be used to parties with vested interests to exaggerate or misrepresent facts, but it's unfortunate when parties from whom you may not expect a clear bias continue to perpetuate uncertainty and doubt.
Article 13 states that the measures to seek rightholder approval for user-submitted content "shall be effective and proportionate, taking into account, among other factors" the nature and size of services, whether they're a small and medium business, the sheer volume of material uploaded, and the cost burden of such an effort.
Furthermore, it refers to a precise definition of the sort of enterprise that is to be impacted by this regime -- those that provide "public access to a large amount of works or other subject-matter uploaded by its users which it organises and promotes for profit-making purposes", exempting a variety of others. This leaves ample leeway to require a more rigorous scheme from hosts as big as YouTube while being more lenient with a hobbyist forum.
Article 11 states that the copyright protection of journalistic articles from aggregators will expire at the end of the following year from the article's publication. It reaffirms the right of publishers to decide how they wish to profit from their work -- if they choose to make it available for the aggregator at no cost, that is their right as well.