bigmushroom

About

Username
bigmushroom
Joined
Visits
38
Last Active
Roles
member
Points
297
Badges
0
Posts
87
  • Google details new Drive for Desktop client replacing Backup and Snyc

    focher said:
    It’s definitely better on its own, but there’s one use case that it’s really terrible for. If you use a personal Google Drive account and a company one under Google Workspace (formerly G Suite) then you can’t access both at the same time. You have to switch accounts. Previously, you could just run Backup and Sync at the same time as Google Drive to give parallel access to both.
    The new app allows you to use up to 4 accounts. So I have my personal account and work account and they show up as two separate drives.
    dope_ahmineAlex_Vdewmeneilmwatto_cobra
  • Fourth macOS Big Sur beta adds support for 4K YouTube playback in Safari

    lkrupp said:
    And people call Apple a bully. Google comes up with its own, proprietary codec and then refuses to support the industry standard H.265, finally bullying Apple into using it. Scratch your ass, Google.
    VP9 is an open-source and royalty-free codect and the basis for Av1 which is also royalty free and Apple is a founding member of the Alliance for Open Media that developed this codec (and which Apple committee to support - if you support AV1 you might as well support VP9 which is quite similar).

    H265 is a standard but you have to pay royalties to at least 3 patent pools and the royalty fees are much, much higher than for H264. That is the reason why streaming media companies don't use it - Netflix, Amazon etc all use h264 and plan to switch to AV1.
    fastasleepwilliamlondon
  • Apple clarifies Safari Safe Browsing feature following Tencent data reports [u]

    DAalseth said:
    corp1 said:
    Great, now we know how it actually works:
    1. Tencent makes a list of "suspicious" URLs (malware, pro-democracy, etc.)
    2. It hashes all the URLs and makes the list available for download. It retains a map of all of the hashes and the URLs for each hash.
    3. Safari downloads the hash list.
    4. Whenever you try to visit a URL whose hash is on the list, Safari phones home to Tencent and tells them the hash (revealing your IP address in the process.)
    5. Tencent looks up the suspicious URL list (URLs matching that hash) in its hash->URL map and returns the suspicious URL list to Safari.
    6. Tencent logs your IP address, the hash/list of suspicious URLs, and the timestamp
    7. If the URL is actually on the suspicious URL list, Safari blocks the site saying that it is suspicious.
    8. Tencent forwards the information (IP address, time/date, list of suspicious URLs that you might have been trying to visit) to the appropriate Chinese authorities for further investigation.
    9. Profit!


    Nope. The hash list is local. Nothing goes from your device to Tencent.
    Without further info this doesn't make sense.

    If the hash list were local then there wouldn't be a need to ping tencent or Google. Years ago chrome had a bloom filter with such urls inside chrome but even that was quite large and they switched to a cloud based system.

    Hashing itself doesn't make anything private except during because transport  the receiver knows the crosswalk between urls and hashes. Exception if somehow apple would hash it themselves but then they could host this service and tencent would not have to be involved at all.

    Maybe apple just sends domain in which case it's correct that the full URL isn't sent. But it would still reveal to Tencent that user X browsed freetibet.org or that you browse Western news or whatever else.
    gatorguy
  • Tim Cook defends choice to pull Hong Kong police monitoring app from App Store

    tzeshan said:
    But I have publicized it on some Chinese web site. 
    Nice to know there is some good patriotic Chinese informers like yourself who tell the Chinese government whom else to pressure and blackmail. While you are at it, while you don't you tell your handlers to take a bit easier on those millions of Uyghurs they locked up in concentration camps (sorry - education camps). Some of those stupid Westerners have started to notice. 

    Just a guess - Google probably doesn't care as much about China since they essentially left in 2009 and don't have much activity left there. Unlike Apple.
    john.bblue orangeJWSC
  • Google is downplaying Android to focus its future on Chrome OS

    command_f said:
    Thoughtful article, thank you.

    Google's appropriation of Java does seem to me to be morally, even if not legally, wrong and I respect Oracle for pursuing the case. That said, I'm not sure that (hypothetically) abandoning Android would be an adequate strategy for avoiding any ultimate verdict in Oracle's favour. Any such settlement would likely allow for continuing use of Android through licensing (or whatever) for huge numbers of existing and updatable devices. Unless Google just abandoned the entire user base, which seems unlikely.
    1) The Oracle/Google trial affects the Android runtime (which exposes the Java API) - the virtual machine that runs Google Play apps. It does not matter whether this runtime is running on the Android kernel, on Chrome OS or on Fuchsia OS. If Google wanted to avoid the Oracle troubles they would have to abandon their app store. That's not going to happen since it's central to Chrome OS now too. So any switch from Android to Chrome OS to run the Google Play apps is not motivated by this trial.

    2) Whatever happens with the trial it will unlikely affect the current Android runtime. The trial is still about Google's Java API implementation based on the Apache Harmony implementation which Google used until 2016. With Android 7, Google switched to the openJDK version of the Java API which Sun licensed under GPL+classpath exception which essentially is equivalent to the LGPL (which means that apps on the Play Store can be closed source). So whatever happens with the current trial, it will cover damages up to Android 6 which is on the way out. By the time there will be any type of resolution, Oracle might get some damages for past infringement, but this would unlikely extend to any current versions of the Android app runtime.

    3) Google cares about the Google Play apps - this is where all the network effects are. It doesn't matter whether this is running on Android kernel or Chrome OS. So why Chrome OS? First of all, there might be some technical reasons since it's a very secure design. But the main reason might be that Chrome OS cannot be modified by manufacturers: it's meant to be shipped and updated centrally by Google - much like Apple does with iOS. 

    In 2008, when the first Android phones came out, the Android market (precursor of the Play store) had no apps - Google had no bargaining power and had to allow manufacturers to modify the kernel and skin the OS.

    However, now Google built a large app store that can run on any kernel. It makes sense to leverage this by slowing abandoning Android and instead have future versions of Google Play run on Chrome OS and Fuchsia OS where Google controls the user experience completely. Google has enough influence now thanks to the Play store that it can slowly push OEMs to Chrome OS.

    Google has every reason to prefer Chrome OS tablets over Android tablets - there is no fragmentation in Chrome OS, no skins, no pesky Samsungs that duplicate all of Google's services etc.

    Maybe Samsung will soon have to develop Android on its own to keep up with new versions of the Play store - but given Samsung's poor record with software they would probably mess it up, and apps would run unreliably. 


    avon b7gatorguycommand_fcornchipjellybellyChris46watto_cobramuthuk_vanalingam